• Oskar Linde (47/47) Dec 07 2007 Since everyone is doing it, the peer pressure got too heavy and I just
• Paul Anderson (5/18) Dec 07 2007 I like the orthogonal emphasis of this proposal. Rather than having to d...
• Paul Anderson (5/18) Dec 07 2007 I like the orthogonal emphasis of this proposal. Rather than having to d...
• bearophile (4/6) Dec 07 2007 Your idea starts to be readable. I don't like the syntax enough yet, but...

Oskar Linde <oskar.lindeREM OVEgmail.com> writes:

Since everyone is doing it, the peer pressure got too heavy and I just 
felt I too had to make a const proposal ready to be shot down.  :)

Anyway, here is a very simple orthogonal const proposal that I believe 
catches most of the earlier suggestions in a more concise way.

Since the table below probably will become squished by the news reader, 
I made a small PDF:

http://www.csc.kth.se/~ol/const.pdf

Please prime and load your muskets. Enjoy :)

The same text as in the PDF follows:

== Definitions
*Values* are physical entities that occupy memory. A value can be either 
variable or constant. All values have a type. Examples of values in D are:
- basic types
- structs
- array slices (8 bytes on a 32 bit architecture)
- pointers (4 bytes on a 32 bit architecture)
- class references (4 bytes on a 32 bit architecture)

*References* are values that in some way refer to other values. 
References have access modes. In this proposal, for simplicity, there 
are only two different access modes: read-write and transitively read-only.

== Descriptions of earlier D const designs
In the first const iteration:
const      sets the read-only access mode
invariant  sets the read-only access mode and defines the
            /target value/ to be constant
final       defines the value to be constant

In the last const iteration:
const      sets the read-only access mode and defines the
            value to be constant
invariant  sets the read-only access mode and defines the
            value to be constant and defines the target
            value to be constant

== New suggested const design
const      defines the value to be constant
in         sets the read-only access mode (readonly would be
            an obvious alternative)

== Comparisons with earlier const iterations

first iteration         last iteration            new suggestion
const int *            TailConst!(int *) (?)     in int *
invariant int *        TailInvariant!(int *) (?) const(int) *
final invariant(int) *  invariant int *           const const(int) *
const Class            TailConst!(Class) (?)     in Class
final const Class       const Class (?)           const in Class
invariant(char)[]      invariant(char)[]         const(char)[]
final invariant(char)[] invariant char[]          const const(char)[]

-- 
Oskar

Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:

Oskar Linde Wrote:

 Since everyone is doing it, the peer pressure got too heavy and I just 
 felt I too had to make a const proposal ready to be shot down.  :)
 
 Anyway, here is a very simple orthogonal const proposal that I believe 
 catches most of the earlier suggestions in a more concise way.
 
 Since the table below probably will become squished by the news reader, 
 I made a small PDF:
 
 http://www.csc.kth.se/~ol/const.pdf
 
 Please prime and load your muskets. Enjoy :)
 

I like the orthogonal emphasis of this proposal. Rather than having to decide
what "const" means in a particular context, it always means the same thing.
Ditto for "in" (I prefer "readonly"). 

If these keywords can capture all the varieties of const/invariant that have
been proposed I would vote for it.

I'll take a look at this vs. guslay's list of const meanings and, unless
someone beats me to it, post the results.

Paul

Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:

Oskar Linde Wrote:

 Since everyone is doing it, the peer pressure got too heavy and I just 
 felt I too had to make a const proposal ready to be shot down.  :)
 
 Anyway, here is a very simple orthogonal const proposal that I believe 
 catches most of the earlier suggestions in a more concise way.
 
 Since the table below probably will become squished by the news reader, 
 I made a small PDF:
 
 http://www.csc.kth.se/~ol/const.pdf
 
 Please prime and load your muskets. Enjoy :)
 

I like the orthogonal emphasis of this proposal. Rather than having to decide
what "const" means in a particular context, it always means the same thing.
Ditto for "in" (I prefer "readonly"). 

If these keywords can capture all the varieties of const/invariant that have
been proposed I would vote for it.

I'll take a look at this vs. guslay's list of const meanings and, unless
someone beats me to it, post the results.

Paul

bearophile <bearophileHUGS lycos.com> writes:

Oskar Linde:
 Anyway, here is a very simple orthogonal const proposal that I believe 
 catches most of the earlier suggestions in a more concise way.

Your idea starts to be readable. I don't like the syntax enough yet, but I like
its being orthogonal. So I think it can be improved still, keeping it
orthogonal.

Bye,
bearophile