View mode: basic / threaded / horizontal-split · Log in · Help
July 05, 2005
Round IV, Classification of results. Immutable arrays...
Attached is a classification table of results we've got on round III.

Clearly there are just two types of constness proposed:
Deep (C++)  - I assume it is proposal #1;
and Shallow (#, Delphi, etc) - proposals #2, #3, #4

Case #5 (Ben, Walter) is not clear for such Shallow/Deep classifcation.

Simple description of constness types (immutability types) is in document
attached.

Javari Language - Java extended by readonly and mutable keywords:
"A Practical Type System and Language for Reference Immutability"
http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf

More deep classification can be found here:
"Immutable objects in Java"
http://www-sop.inria.fr/everest/events/cassis05/Transp/poll.pdf

Andrew.
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:
> Attached is a classification table of results we've got on round III.
>
> Clearly there are just two types of constness proposed:
> Deep (C++)  - I assume it is proposal #1;

Wasn't Walters arguments/points that C++ const is not "deep"?

Regan
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
Thanks for the references, those are good reads.
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
Case #5 (Ben, Walter) is not clear for such Shallow/Deep classifcation.

Note in/out/final wouldn't be type modifiers. Actually that could make the 
'out' suggestion I had impractical - but since that was a brainstorming 
request I didn't bother thinking if the idea was implementable or not ;-)
Also Walter's suggestion would apply to any reference-based semantics - not 
just arrays and pointers.
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
"Regan Heath" <regan@netwin.co.nz> wrote in message
news:opstgtnrii23k2f5@nrage.netwin.co.nz...
> On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk 
> <news@terrainformatica.com> wrote:
>> Attached is a classification table of results we've got on round III.
>>
>> Clearly there are just two types of constness proposed:
>> Deep (C++)  - I assume it is proposal #1;
>
> Wasn't Walters arguments/points that C++ const is not "deep"?
>
> Regan


C++:-----------------------------------------------------
class Field
{
  private string _name;
  const string& name() const { return _name; }
  void   name(const string& nn) { _name = nn; }
}

int foo(const Field[] a)
{
  string s = a[0].name(); //ok
  a[0].name("Hello"); // compile time error;
           // attempt to modify const object a[0]
  a[0] = Field(); // CT error
}

As you may see C++ protects const array deeply -
you cannot modify neither array itself nor its members
nor members of members, etc.

Proposed "shallow" schema:---------------------

class Field
{
  private char[] _name;
  char#[] name() { return _name; }
  void  name( char#[] nn) { _name = nn.dup; }
}

int foo(Field#[] a)
{
  string s = a[0].name; //ok
  a[0].name = "Hello"; // ok
  a[0] = new Field(); // compile time error:
        // #[] has no opIndexAssign method
  a.length = 0; // compile time error:
        // #[] has no length( newLength) method.
}

Eugene's variant ----------------------------------------
( all arrays are read only by default )

class Field
{
  private var char[] _name;
  char[] name() { return _name; }
  void  name( char[] nn) { _name = nn.dup; }
}

int foo(Field[] a)
{
  string s = a[0].name; //ok
  a[0].name = "Hello"; // ok
  a[0] = new Field(); // compile time error:
        // [] has no opIndexAssign method
  a.length = 0; // compile time error:
        // [] has no length( newLength) method.
}

Andrew.
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
I'm referring to...

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26148
"On the other hand, look at C++ "const". Nothing about "const" says that  
some
other thread or reference cannot change the value out from under you at any
moment. Furthermore, it can be cast away and modified anyway. The semantic
value of C++ "const" is essentially zip. This is why I am often flummoxed
why it is given such weight in C++."

In contrast Walters idea is true "deep" immutability:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096
"Deep immutable parameters would have unchanging values for the scope of  
that
parameter, and also every sub-object reachable by that parameter would also
be unchangeable. The values wouldn't change even by another reference or
another thread. (This is quite unlike C++ "const".)"

In other words, Walters idea is "deep", C++ is not.

Regan

On Tue, 5 Jul 2005 19:12:19 -0700, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opstgtnrii23k2f5@nrage.netwin.co.nz...
>> On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> Attached is a classification table of results we've got on round III.
>>>
>>> Clearly there are just two types of constness proposed:
>>> Deep (C++)  - I assume it is proposal #1;
>>
>> Wasn't Walters arguments/points that C++ const is not "deep"?
>>
>> Regan
>
>
> C++:-----------------------------------------------------
> class Field
> {
>    private string _name;
>    const string& name() const { return _name; }
>    void   name(const string& nn) { _name = nn; }
> }
>
> int foo(const Field[] a)
> {
>    string s = a[0].name(); //ok
>    a[0].name("Hello"); // compile time error;
>             // attempt to modify const object a[0]
>    a[0] = Field(); // CT error
> }
>
> As you may see C++ protects const array deeply -
> you cannot modify neither array itself nor its members
> nor members of members, etc.
>
> Proposed "shallow" schema:---------------------
>
> class Field
> {
>    private char[] _name;
>    char#[] name() { return _name; }
>    void  name( char#[] nn) { _name = nn.dup; }
> }
>
> int foo(Field#[] a)
> {
>    string s = a[0].name; //ok
>    a[0].name = "Hello"; // ok
>    a[0] = new Field(); // compile time error:
>          // #[] has no opIndexAssign method
>    a.length = 0; // compile time error:
>          // #[] has no length( newLength) method.
> }
>
> Eugene's variant ----------------------------------------
> ( all arrays are read only by default )
>
> class Field
> {
>    private var char[] _name;
>    char[] name() { return _name; }
>    void  name( char[] nn) { _name = nn.dup; }
> }
>
> int foo(Field[] a)
> {
>    string s = a[0].name; //ok
>    a[0].name = "Hello"; // ok
>    a[0] = new Field(); // compile time error:
>          // [] has no opIndexAssign method
>    a.length = 0; // compile time error:
>          // [] has no length( newLength) method.
> }
>
> Andrew.
>
>
>
>
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
"Walter" <newshound@digitalmars.com> wrote in message 
news:daf95o$15e6$1@digitaldaemon.com...
Thanks for the references, those are good reads.

Yep, the best thing that they are essential - 30 slides.
"brevity is a sister of talent" as they say.

Andrew.
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
"Regan Heath" <regan@netwin.co.nz> wrote in message 
news:opstgz4wiy23k2f5@nrage.netwin.co.nz...
> I'm referring to...
>
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26148
> "On the other hand, look at C++ "const". Nothing about "const" says that 
> some
> other thread or reference cannot change the value out from under you at 
> any
> moment. Furthermore, it can be cast away and modified anyway. The semantic
> value of C++ "const" is essentially zip. This is why I am often flummoxed
> why it is given such weight in C++."
>
> In contrast Walters idea is true "deep" immutability:
> http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/26096
> "Deep immutable parameters would have unchanging values for the scope of 
> that
> parameter, and also every sub-object reachable by that parameter would 
> also
> be unchangeable. The values wouldn't change even by another reference or
> another thread. (This is quite unlike C++ "const".)"
>
> In other words, Walters idea is "deep", C++ is not.

Arghhh! :)

C++ uses abstract model of deep immutability. (Read links I've provided)
But in practice...

Epic picture "Devastation of Beaitiful Idea by Disgusting Fact" to be short.

Compromises, compromises....

Andrew.

>
> Regan
>
> On Tue, 5 Jul 2005 19:12:19 -0700, Andrew Fedoniouk 
> <news@terrainformatica.com> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opstgtnrii23k2f5@nrage.netwin.co.nz...
>>> On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk
>>> <news@terrainformatica.com> wrote:
>>>> Attached is a classification table of results we've got on round III.
>>>>
>>>> Clearly there are just two types of constness proposed:
>>>> Deep (C++)  - I assume it is proposal #1;
>>>
>>> Wasn't Walters arguments/points that C++ const is not "deep"?
>>>
>>> Regan
>>
>>
>> C++:-----------------------------------------------------
>> class Field
>> {
>>    private string _name;
>>    const string& name() const { return _name; }
>>    void   name(const string& nn) { _name = nn; }
>> }
>>
>> int foo(const Field[] a)
>> {
>>    string s = a[0].name(); //ok
>>    a[0].name("Hello"); // compile time error;
>>             // attempt to modify const object a[0]
>>    a[0] = Field(); // CT error
>> }
>>
>> As you may see C++ protects const array deeply -
>> you cannot modify neither array itself nor its members
>> nor members of members, etc.
>>
>> Proposed "shallow" schema:---------------------
>>
>> class Field
>> {
>>    private char[] _name;
>>    char#[] name() { return _name; }
>>    void  name( char#[] nn) { _name = nn.dup; }
>> }
>>
>> int foo(Field#[] a)
>> {
>>    string s = a[0].name; //ok
>>    a[0].name = "Hello"; // ok
>>    a[0] = new Field(); // compile time error:
>>          // #[] has no opIndexAssign method
>>    a.length = 0; // compile time error:
>>          // #[] has no length( newLength) method.
>> }
>>
>> Eugene's variant ----------------------------------------
>> ( all arrays are read only by default )
>>
>> class Field
>> {
>>    private var char[] _name;
>>    char[] name() { return _name; }
>>    void  name( char[] nn) { _name = nn.dup; }
>> }
>>
>> int foo(Field[] a)
>> {
>>    string s = a[0].name; //ok
>>    a[0].name = "Hello"; // ok
>>    a[0] = new Field(); // compile time error:
>>          // [] has no opIndexAssign method
>>    a.length = 0; // compile time error:
>>          // [] has no length( newLength) method.
>> }
>>
>> Andrew.
>>
>>
>>
>>
>
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk  
<news@terrainformatica.com> wrote:
> Attached is a classification table of results we've got on round III.
>
> Clearly there are just two types of constness proposed:
> Deep (C++)  - I assume it is proposal #1;
> and Shallow (#, Delphi, etc) - proposals #2, #3, #4
>
> Case #5 (Ben, Walter) is not clear for such Shallow/Deep classifcation.
>
> Simple description of constness types (immutability types) is in document
> attached.
>
> Javari Language - Java extended by readonly and mutable keywords:
> "A Practical Type System and Language for Reference Immutability"
> http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf

This document pretty much describes exactly the 'readonly' idea I have  
been posting for the past few weeks.

Minor differences include:
 - They've detailed how to flag methods as 'readonly safe'
 - They've detailed a downcast mechanism 'mutable'.
 - I used 'in' rather than 'readonly' to identify readonly function  
arguments.
 - They restricted the idea to references.

The "Dynamic checking for downcasts" section describes my runtime readonly  
flag concept (restricted to references).

Regan
July 06, 2005
Re: Round IV, Classification of results. Immutable arrays...
"Regan Heath" <regan@netwin.co.nz> wrote in message 
news:opstg4vfvz23k2f5@nrage.netwin.co.nz...
> On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk 
> <news@terrainformatica.com> wrote:
>> Attached is a classification table of results we've got on round III.
>>
>> Clearly there are just two types of constness proposed:
>> Deep (C++)  - I assume it is proposal #1;
>> and Shallow (#, Delphi, etc) - proposals #2, #3, #4
>>
>> Case #5 (Ben, Walter) is not clear for such Shallow/Deep classifcation.
>>
>> Simple description of constness types (immutability types) is in document
>> attached.
>>
>> Javari Language - Java extended by readonly and mutable keywords:
>> "A Practical Type System and Language for Reference Immutability"
>> http://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf
>
> This document pretty much describes exactly the 'readonly' idea I have 
> been posting for the past few weeks.
>
> Minor differences include:
>  - They've detailed how to flag methods as 'readonly safe'
>  - They've detailed a downcast mechanism 'mutable'.
>  - I used 'in' rather than 'readonly' to identify readonly function 
> arguments.
>  - They restricted the idea to references.
>
> The "Dynamic checking for downcasts" section describes my runtime readonly 
> flag concept (restricted to references).
>
> Regan

Regan,
general idea: if something could be done in compile time
than it shall be done there. As you may see there is a penalty
on runtime readonly checks ( <= 10% ) - not good.

As stated in first article it is possible to prove immutability
in "99.something %". I think it is enough.

I even think that even 50% cases (shallow) in compile time will be extremely
nice.

IMHO: shallow implementation is a) essential, b) easily implementable,
c) effective and d) honest . Yes it is compromise but as an exit condition 
for v.1.0
it is sufficient. It also allows to build full immutability system in v.2.0.
IMHO, IMHO and one more time IMHO.

Andrew.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home