www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Huh, invariant() {...} ?

reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
This is a small detail, but I found myself wondering why the class  
invariant declarations have now parenthesis (in 2.0, that is).

I mean, you cannot write something like this:

   invariant {
     int* p;  //invariant int* p;
   }

Or can you?


The class invariant declarations are no longer consistent with other class  
blocks, which is a shame.

   class A {
     invariant() {  //hmmm, should I put parens here or not?
       ...
     }
     unittest {  //how about here?
       ...
     }
   }


It may be clearer anyway to use different keyword for the class  
invariants, 'classinvariant' or something.

Or change the new 'invariant' keyword to 'invar'...

   const int* p1;
   invar int* p2;

(Less typing, and then both the keywords would be 5 chars long (a little  
bonus).)
Jun 18 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Kristian Kilpi wrote:

 
 This is a small detail, but I found myself wondering why the class 
 invariant declarations have now parenthesis (in 2.0, that is).


It was to remove syntactical ambiguities.
Jun 18 2007
next sibling parent reply Myron Alexander <someone somewhere.com> writes:
Walter Bright wrote:

 Kristian Kilpi wrote:

 This is a small detail, but I found myself wondering why the class 
 invariant declarations have now parenthesis (in 2.0, that is).


 
 It was to remove syntactical ambiguities.


Walter,

I have nothing against the invariant() syntax. The word invariant has 
specific meaning for contracts but not necessarily for variables.

Was the keyword "immutable" considered and rejected? I only ask because 
you have two semantics for one keyword: one meaning DbC test, another 
meaning changeless value.

Regards,

Myron.
Jun 18 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Myron Alexander wrote:

 Was the keyword "immutable" considered and rejected?


Yes, because invariant would serve, and because C++ seems to have left 
immutable with a bad taste in the mouth :-)
Jun 18 2007
parent Myron Alexander <someone somewhere.com> writes:
Walter Bright wrote:

 Yes, because invariant would serve, and because C++ seems to have left 
 immutable with a bad taste in the mouth :-)


:) Ok, thanks for the clarification.
Jun 18 2007
prev sibling next sibling parent reply "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Mon, 18 Jun 2007 21:25:32 +0300, Walter Bright  
<newshound1 digitalmars.com> wrote:

 Kristian Kilpi wrote:

  This is a small detail, but I found myself wondering why the class  
 invariant declarations have now parenthesis (in 2.0, that is).


 It was to remove syntactical ambiguities.


Oh I see, as Deewiant said in another reply to my original post, one *can*  
write 'invariant {...}' now... (so, yep, it cannot be used for the class  
invariants).

Too much keywords in a language is not good, but maybe a new keyword (e.g.  
'classinvariant') for the class invariants would be justified. Semantic  
ambiguity is not nice either.
Jun 18 2007
parent reply Henning Hasemann <hhasemann web.de> writes:
Am Mon, 18 Jun 2007 22:08:47 +0300
schrieb "Kristian Kilpi" <kjkilpi gmail.com>:


 Too much keywords in a language is not good, but maybe a new keyword
 (e.g. 'classinvariant') for the class invariants would be justified.
 Semantic ambiguity is not nice either.


I think that is a common mistake. Maybe too many different *meanings*
or techniques or whatever in a language are not good.
I cant imagine why it should be better to have very few keywords with
each relatively much different meanings than more with each a unique or
just few meanings considering ease of coding and understanding written
code.

The only argument against new keywords for new compiler-features that
can not be expressed as library functions is, that they might pollute
different namespaces such as the one for modules or variable names.

But maybe the right approach then is not to reduce the number of
keywords but build up a syntax that makes it always possible to
distinguish a user-defined name from a keyword.

For example in

const invariant int const;

its clear that the last const would be the variable name even it is a
keyword too. I agree that this is *pretty* ugly, but I recently wanted
to create a module that defines the base class for all possible
interfaces (ie user interfaces) to my program. Naming it "interface"
was a bad idea. I came up very quickly with "ui" but there may be
situations where it is not that easy to find a pleasant name.
(Names *are* important!)

So for a summary: I dont expect to find such an idea in a D release that
comes out this decade, I'm just "thinking around", maybe someone has
some interesting comments / ideas on this?!

Henning

-- 
GPG Public Key:
http://keyserver.ganneff.de:11371/pks/lookup?op=get&search=0xDDD6D36D41911851
Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851
Jun 18 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Henning Hasemann wrote:

 Am Mon, 18 Jun 2007 22:08:47 +0300
 schrieb "Kristian Kilpi" <kjkilpi gmail.com>:

 But maybe the right approach then is not to reduce the number of
 keywords but build up a syntax that makes it always possible to
 distinguish a user-defined name from a keyword.
 
 For example in
 
 const invariant int const;
 
 its clear that the last const would be the variable name even it is a
 keyword too. 


The thing Walter has responded before about such comments is that it 
makes the grammar non-context free.  The lexer has to become intertwined 
with semantic analysis to know for sure if each word encountered really 
is a keyword or not.  It's not impossible, but one of Walter's big goals 
for D is to have a simpler grammar than C++ (while at the same time 
being more productive than C++).  Having a simple grammar makes it more 
likely that external tools will be able to do a good job parsing it, and 
that anyone who sets out to implement a D compiler will have less 
trouble doing so.

--bb
Jun 18 2007
prev sibling parent reply Derek Parnell <derek nomail.afraid.org> writes:
On Mon, 18 Jun 2007 11:25:32 -0700, Walter Bright wrote:


 Kristian Kilpi wrote:

 
 This is a small detail, but I found myself wondering why the class 
 invariant declarations have now parenthesis (in 2.0, that is).


 
 It was to remove syntactical ambiguities.


 ... at the cost of understanding for humans ... 

The "overloaded" keyword problem with D is just getting worse and worse. 

I know you are a compiler writer and doing such things as you are makes it
easier for the compiler, but the continually overloading of keywords with
different (but similar) meanings in D is bordering on the illegible. What
you are doing, inadvertently, is making D harder for people to learn,
understand, and read.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Justice for David Hicks!"
19/06/2007 12:02:06 PM
Jun 18 2007
next sibling parent "Kristian Kilpi" <kjkilpi gmail.com> writes:
On Tue, 19 Jun 2007 05:06:08 +0300, Derek Parnell  
<derek nomail.afraid.org> wrote:


 On Mon, 18 Jun 2007 11:25:32 -0700, Walter Bright wrote:


 Kristian Kilpi wrote:

 This is a small detail, but I found myself wondering why the class
 invariant declarations have now parenthesis (in 2.0, that is).


 It was to remove syntactical ambiguities.


  ... at the cost of understanding for humans ...

 The "overloaded" keyword problem with D is just getting worse and worse.

 I know you are a compiler writer and doing such things as you are makes  
 it
 easier for the compiler, but the continually overloading of keywords with
 different (but similar) meanings in D is bordering on the illegible. What
 you are doing, inadvertently, is making D harder for people to learn,
 understand, and read.


I agree.

(I have a feeling that Walter is reluctant to do something like this, but)  
if the keyword for the class invariants will be changed, I vote for:

   invarianttest

It's similar to 'unittest', and who knows, maybe there will be structure  
invariants someday also.
Jun 19 2007
prev sibling parent Serg Kovrov <kovrov bugmenot.com> writes:
Derek Parnell wrote:

 The "overloaded" keyword problem with D is just getting worse and worse. 
 
 I know you are a compiler writer and doing such things as you are makes it
 easier for the compiler, but the continually overloading of keywords with
 different (but similar) meanings in D is bordering on the illegible. What
 you are doing, inadvertently, is making D harder for people to learn,
 understand, and read.


I think so. The 'mixin' keyword is a similar example as well. I think 
for string evaluation it should be 'eval' (as in other languages).


-- serg.
Jun 28 2007
prev sibling next sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Kristian Kilpi wrote:

 This is a small detail, but I found myself wondering why the class
 invariant declarations have now parenthesis (in 2.0, that is).
 
 I mean, you cannot write something like this:
 
   invariant {
     int* p;  //invariant int* p;
   }
 
 Or can you?
 


You can, which is exactly why.
Jun 18 2007
prev sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
This can only be a win!

1. If the invariant keyword will be left with those two meaning, than 
for consistency unit tests should be written:

unittest() {
}

Which leaves the possibility to specify something between the parens:

unittest("List adds correctly an element") {
}

and then when an assert fails within a unittest, that message could also 
be displayed.

Also a string could be specified in a class invariant, with the same 
purpose.

2. If one of the invariant keyword will be changed by another 
(classinvariant) or (immutable), that everything will be clearer.

:)

Kristian Kilpi escribió:

 
 This is a small detail, but I found myself wondering why the class 
 invariant declarations have now parenthesis (in 2.0, that is).
 
 I mean, you cannot write something like this:
 
   invariant {
     int* p;  //invariant int* p;
   }
 
 Or can you?
 
 
 The class invariant declarations are no longer consistent with other 
 class blocks, which is a shame.
 
   class A {
     invariant() {  //hmmm, should I put parens here or not?
       ...
     }
     unittest {  //how about here?
       ...
     }
   }
 
 
 It may be clearer anyway to use different keyword for the class 
 invariants, 'classinvariant' or something.
 
 Or change the new 'invariant' keyword to 'invar'...
 
   const int* p1;
   invar int* p2;
 
 (Less typing, and then both the keywords would be 5 chars long (a little 
 bonus).)
Jun 18 2007
parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Ary Manzana wrote:

 [...]
 unittest() {
 }
 
 Which leaves the possibility to specify something between the parens:
 
 unittest("List adds correctly an element") {
 }
 
 and then when an assert fails within a unittest, that message could also 
 be displayed.
 [...]


I proposed something very much like that, and even coded up the 
front-end portion, so that one could construct a library that is a 
worthy competitor to JUnit et al, but nobody was interested (Andrei even 
went so far as to mock it!...but I don't think his xUnit-foo is up to 
snuff ;).

Dave
Jun 28 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
If it compiles under 2.001, any way you could post it up here, please? Sounds
useful. I've been eying Thomas Khune's UnittestWalker which is powerful, but
nothing like a real language extension.

David B. Held Wrote:


 Ary Manzana wrote:

 [...]
 unittest() {
 }
 
 Which leaves the possibility to specify something between the parens:
 
 unittest("List adds correctly an element") {
 }
 
 and then when an assert fails within a unittest, that message could also 
 be displayed.
 [...]


 
 I proposed something very much like that, and even coded up the 
 front-end portion, so that one could construct a library that is a 
 worthy competitor to JUnit et al, but nobody was interested (Andrei even 
 went so far as to mock it!...but I don't think his xUnit-foo is up to 
 snuff ;).
 
 Dave
Jun 29 2007
parent "David B. Held" <dheld codelogicconsulting.com> writes:
Robert Fraser wrote:

 If it compiles under 2.001, any way you could post it up here, please? Sounds
useful. I've been eying Thomas Khune's UnittestWalker which is powerful, but
nothing like a real language extension.


I couldn't finish it because I didn't have the back end to build it 
with.  I suppose I could try hacking GDC, though.

Dave
Jun 29 2007