View mode: basic / threaded / horizontal-split · Log in · Help
June 18, 2007
Huh, invariant() {...} ?
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).)
June 18, 2007
Re: Huh, invariant() {...} ?
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.
June 18, 2007
Re: Huh, invariant() {...} ?
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.
June 18, 2007
Re: Huh, invariant() {...} ?
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.
June 18, 2007
Re: Huh, invariant() {...} ?
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.
June 18, 2007
Re: Huh, invariant() {...} ?
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).)
June 18, 2007
Re: Huh, invariant() {...} ?
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
June 18, 2007
Re: Huh, invariant() {...} ?
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 :-)
June 18, 2007
Re: Huh, invariant() {...} ?
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.
June 19, 2007
Re: Huh, invariant() {...} ?
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home