Thread overview | ||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 05, 2005 Round IV, Classification of results. Immutable arrays... | ||||
---|---|---|---|---|
| ||||
Attachments: | 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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk Attachments:
| Thanks for the references, those are good reads. |
July 06, 2005 Re: Round IV, Classification of results. Immutable arrays... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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... | ||||
---|---|---|---|---|
| ||||
Posted in reply to Regan Heath | "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. |
Copyright © 1999-2021 by the D Language Foundation