Jump to page: 1 2
Thread overview
Huh, invariant() {...} ?
Jun 18, 2007
Kristian Kilpi
Jun 18, 2007
Walter Bright
Jun 18, 2007
Myron Alexander
Jun 18, 2007
Walter Bright
Jun 18, 2007
Myron Alexander
Jun 18, 2007
Kristian Kilpi
Jun 18, 2007
Henning Hasemann
Jun 19, 2007
Bill Baxter
Jun 19, 2007
Derek Parnell
Jun 19, 2007
Kristian Kilpi
Jun 28, 2007
Serg Kovrov
Jun 18, 2007
Deewiant
Jun 18, 2007
Ary Manzana
Jun 29, 2007
David B. Held
Jun 29, 2007
Robert Fraser
Jun 30, 2007
David B. Held
June 18, 2007
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
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
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
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
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
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
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
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
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
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