digitalmars.D - Round IV, Classification of results. Immutable arrays...
- Andrew Fedoniouk (115/115) Jul 05 2005 Attached is a classification table of results we've got on round III.
- Regan Heath (4/7) Jul 05 2005 Wasn't Walters arguments/points that C++ const is not "deep"?
- Andrew Fedoniouk (54/62) Jul 05 2005 C++:-----------------------------------------------------
- Regan Heath (19/82) Jul 05 2005 I'm referring to...
- Andrew Fedoniouk (8/108) Jul 05 2005 Arghhh! :)
- Walter (3/3) Jul 05 2005 charset="iso-8859-1"
-
Andrew Fedoniouk
(6/6)
Jul 05 2005
"Walter"
- Ben Hinkle (6/6) Jul 05 2005 Case #5 (Ben, Walter) is not clear for such Shallow/Deep classifcation.
- Regan Heath (13/23) Jul 05 2005 This document pretty much describes exactly the 'readonly' idea I have
- Andrew Fedoniouk (16/43) Jul 05 2005 Regan,
- Regan Heath (19/70) Jul 05 2005 Yep.
- Andrew Fedoniouk (37/107) Jul 06 2005 Obviously it is hard to provide numbers here.
- Ben Hinkle (9/15) Jul 06 2005 not to beat a fairly-dead horse but const_cast<> is the least of the
- Andrew Fedoniouk (18/33) Jul 06 2005 Ben, I understand the intention. Theoretically such verification is poss...
- Regan Heath (21/61) Jul 06 2005 This is an important distinction I think many people might miss at first...
- Andrew Fedoniouk (1/7) Jul 06 2005 Exactly!
- Dave (40/55) Jul 08 2005 I can still hear the horse whinnying, so I had to beat it some more (str...
- Regan Heath (38/99) Jul 06 2005 Of course, I agree that CT const is better than RT const. However, if
- Andrew Fedoniouk (62/169) Jul 06 2005 Yes, there are cases when you need deep immutability.
- xxx_one (16/16) Jul 11 2005 class xxx {
Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed: 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. begin 666 constness.htm M;G0M5'EP92( 8V]N=&5N=#TB=&5X="]H=&UL.R!C:&%R<V5T/75T9BTX(CX- M"B (" \345402!N86UE/2)'14Y%4D%43U(B(&-O;G1E;G0](D),3T-+3D]4 M12Y.150B/ T*(" (#Q-151 M3TY4(&9A8V4](E9E<F1A;F$B('-I>F4],CX-"B (" \5$E43$4^/"]4251, M13X\4U193$4^0D]$62![($9/3E0M1D%-24Q9.E9E<F1A;F$[($9/3E0M4TE: M13HQ,'!T('T-"E >R!&3TY4+49!34E,63I697)D86YA.R!&3TY4+5-)6D4Z M;&5F=#X-"CQ404),12!B;W)D97(],2!C96QL<&%D9&EN9STS(&-E;&QS<&%C M:6YG/3$ =VED=& ],3 P)3X-"B /%12/ T*(" (#Q41"!V86QI9VX]=&]P M"B (" \5$0 =F%L:6=N/71O<#Y4>7!E*"HI/"]41#X-"B (" \5$0 =F%L M:6=N/71O<#Y M9VX]=&]P/DYO=&%T:6]N/"]41#X-"B (" \5$0 ;F]W<F%P('9A;&EG;CUT M;W(](V9F96-D.2!V86QI9VX]=&]P/D1E97 H/RD\+U1$/ T*(" (#Q41"!B M9V-O;&]R/2-F9F5C9#D =F%L:6=N/71O<#Y0 M86QI9VX]=&]P/G1Y<&5N86UE(&-O;G-T(%M=+"!T>7!E;F%M92!C;VYS=" J M/"]41#X-"B (" \5$0 ;F]W<F%P(&)G8V]L;W(](V9F96-D.2!V86QI9VX] M=&]P/C$P,#PO5 M;W(](V9F9F9D-R!V86QI9VX]=&]P/E-H86QL;W<\+U1$/ T*(" (#Q41"!B M;6UU=&%B;&4 87)R87D /$)2/F%N9"!I;6UU=&%B;&4 <&]I;G1E<CPO5$0^ M=&]P/E-H86QL;W<\+U1$/ T*(" (#Q41 M:6=N/71O<#Y$96QP:&D <W1Y;&4 8V]N<W1N97-S+"!O;FQY(&9O<B!A<G)A M86QI9VX]=&]P/G1Y<&5N86UE6W)W72P ='EP96YA;65;<F]=/"]41#X-"B M(" \5$0 ;F]W<F%P(&)G8V]L;W(](V9F9F9D-R!V86QI9VX]=&]P/C8P/"]4 M1#X-"B /"]44CX-"B /%12/ T*(" (#Q41 M=F%L:6=N/71O<#XT/"]41#X-"B (" \5$0 8F=C;VQO<CTC9F9F9F0W('9A M;&EG;CUT;W ^175G96YE/"]41#X-"B (" \5$0 8F=C;VQO<CTC9F9F9F0W M9F9D-R!V86QI9VX]=&]P/E!R971T>2!M=6-H(&EN=F5R<V5D('9A<FEA;G0 M>2!B>2!D969A=6QT+B \+U1$/ T*(" (#Q41"!N;W=R87 8F=C;VQO<CTC M9F9F9F0W('9A;&EG;CUT;W ^=F%R('1Y<&5N86UE(%M=("T <F5A9"UW<FET M(#PO5 M=&]P/D)E;B H<F5F(%=A;'1E<BD\+U1$/ T*(" (#Q41"!B9V-O;&]R/2-E M969F9&0 =F%L:6=N/71O<#Y M<CTC965F9F1D('9A;&EG;CUT;W ^17AT96YD:6YG(&UE86YI;F< ;V8 )VEN M)R\G;W5T)R!O<B G9FEN86PG+B \+U1$/ T*(" (#Q41"!N;W=R87 8F=C M;VQO<CTC965F9F1D('9A;&EG;CUT;W ^;W5T('1Y<&5N86UE6UTL(&9I;F%L M96YA;64J/"]41#X-"B (" \5$0 ;F]W<F%P(&)G8V]L;W(](V5E9F9D9"!V M86QI9VX]=&]P/C\\+U1$/ T*(" \+U12/ T*/"]404),13X-"CPO1$E6/ T* M/$1)5CXF;F)S<#L\+T1)5CX-"CQ$258^*"HI(%1Y<&5S(&]F(&-O;G-T;F5S M/ T*/$1)5CXF;F)S<#LF;F)S<#LF;F)S<#M M<&5N86UE6UT\+T5-/B M(&UE86YS('1H870 >6]U(&-A;FYO="!D:7)E8W1L M>2!M;V1I9GD ;65M8F5R<R!O9B!A<G)A>2!N96ET:&5R(&)Y(&%S<VEG;FEN M9R \+T1)5CX-"CQ$258^;F5W('9A;'5E<R!T;R!A<G)A>2!E;&5M96YT<R!N M;W( 8V%L;&EN9R!M971H;V1S(&YO;BUM87)K960 87, /$5-/F-O;G-T/"]% M33X +2!M;V1I9GEI;F< :6YS=&%N8V5S(&5X<&QI8VET;'DN(%1H:7, 87!P M;'D =&\ =&AE('=H;VQE(&1E<'1H(&]F(&]B:F5C="!H:65R86-H>2 M(&EF M(&%R<F%Y<R!C;VYT86EN:6YG(&]B:F5C=', 86YD('1H870 ;V)J96-T<R!C M;VYT86EN(&UE;6)E<B!O8FIE8W1S('1H96X ;6]D:69Y:6YG(&UE=&AO9', M9&ES8F%L960 =&\ =&AE('=H;VQE(&1E<'1H(&]F('-T<G5C='5R97,N(%1H M:7, :7, =VAY($,K*R!C;VYS="!C;VYS:61E<F5D(&%S("9Q=6]T.V-L=71T M97)I;F<F<75O=#L +2 \+T1)5CX-"CQ$258^>6]U(&-A;FYO="!T86ME(&$ M8V]N<W1A;G0 <F5F97)E;F-E('1O('1H92!O8FIE8W0 86YD('!A<W, :70 M=&\ =&AE(&9U;F-T:6]N('=I=& ;F]N+6-O;G-T86YT('!A<F%M971E<B M M(&YE960 =&\ 9&5F:6YE(&-O;G-T(&5V97)Y=VAE<F4N($-L=71T97( 8G5T M('5L=&EM871E("AA<R!D96-L87)A=&EO;B!M971H;V0I+CPO1$E6/ T*/$1) M5CXF;F)S<#L\+T1)5CX-"CQ$258^4VAA;&QO=SH\+T1)5CX-"CQ$258^("9N M8G-P.W1Y<&5N86UE("-;72 M(&UE86YS('1H870 >6]U(&-A;FYO="!D:7)E M8W1L>2!M;V1I9GD ;65M8F5R<R!O9B!A<G)A>2!B>2!A<W-I9VYI;F< ;F5W M('9A;'5E<R!T;R!I=', 96QE;65N=', 86YD('EO=2!C86YN;W0 ;6]D:69Y M(&%R<F%Y(&QE;F=T:"!A<R!I;B!P<F5V:6]U<R!C87-E+B!)9B!M96UB97)S M(&]F('1H92!A<G)A>2!A<F4 <F5F97)E;F-E<R!T;R!O8FIE8W1S('1H96X M=&AI<R!M971H;V0 /%-44D].1SYD;V5S(&YO=#PO4U123TY'/B!P<F]P86=A M=&4 8V]N<W1N97-S('1O(&-O;G1A:6YE9"!O8FIE8W1S+B!3;R!Y;W4 8V%N M(&-A;&P ;65T:&]D<R!M;V1I9GEI;F< ;V)J96-T<R!T:&5M<V5L=F5S+B!4 M:'5S('1H:7, ;65T:&]D(&AA<R F<75O=#MC;'5T=&5R(&9A8W1O<B9Q=6]T M:6]N(')E;6%I;G, ;V8 =VAA="!T;R!D;R!W:71H(&%R<F%Y<R!C;VYT86EN M:6YG('-T<G5C='5R97,N(#PO1$E6/ T*/$1)5CY!<R!S=')U8W1U<F5S(&-O M;G1A:6X ;65M8F5R<R!W:&EC:"!C86X 8F4 86-C97-S960 :6YD97!E;F1E M;G1L>2!T:&5N(&-O;G-T('!R;W1E8W1I;VX <VAO=6QD(&%P<&QY('1O(#PO M1$E6/ T*/$1)5CYT:&%T(&UE;65B97)S(" 86YD(&UE=&AO9', *2!T;V\N %2%1-3#X` ` end
Jul 05 2005
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:Wasn't Walters arguments/points that C++ const is not "deep"? Regan
Jul 05 2005
"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: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; } { string s = a[0].name; //ok a[0].name = "Hello"; // ok a[0] = new Field(); // compile time error: a.length = 0; // compile time error: } 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.Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed:Wasn't Walters arguments/points that C++ const is not "deep"? Regan
Jul 05 2005
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: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; } { string s = a[0].name; //ok a[0].name = "Hello"; // ok a[0] = new Field(); // compile time error: a.length = 0; // compile time error: } 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.Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed:Wasn't Walters arguments/points that C++ const is not "deep"? Regan
Jul 05 2005
"Andrew Fedoniouk" <news terrainformatica.com> "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: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; } { string s = a[0].name; //ok a[0].name = "Hello"; // ok a[0] = new Field(); // compile time error: a.length = 0; // compile time error: } 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.Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed:Wasn't Walters arguments/points that C++ const is not "deep"? Regan
Jul 05 2005
charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the references, those are good reads.
Jul 05 2005
"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.
Jul 05 2005
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.
Jul 05 2005
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: 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.pdfThis 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
Jul 05 2005
"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: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.Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed: 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.pdfThis 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
Jul 05 2005
On Tue, 5 Jul 2005 21:31:57 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:"Regan Heath" <regan netwin.co.nz> wrote in message news:opstg4vfvz23k2f5 nrage.netwin.co.nz...Yep.On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:Regan, general idea: if something could be done in compile time than it shall be done there.Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed: 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.pdfThis 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). ReganAs you may see there is a penalty on runtime readonly checks ( <= 10% )Yep.- not good.You cannot say that, without first weighing the cost up with the benefit. The cost is ____? The benefit is ____? Therefore as cost < benefit, not good.As stated in first articlehttp://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf this one?it is possible to prove immutability in "99.something %". I think it is enough.Where? I must have missed that bit.I even think that even 50% cases (shallow) in compile time will be extremely nice.Define "shallow", because obviously we have different definitions of what exactly it means. "deep" as used by Walter earlier appeared to me to mean "completely and utterly" as in the case where he used it, it guaranteed immutability essentially for the lifetime of the variable/data from all references.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.Once you define "shallow" I'm sure I'll know what you mean, and I'll probably agree. Regan
Jul 05 2005
"Regan Heath" <regan netwin.co.nz> wrote in message news:opstg7lpj923k2f5 nrage.netwin.co.nz...On Tue, 5 Jul 2005 21:31:57 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:Obviously it is hard to provide numbers here. But motivation of doing constness solely in CT is the same as motivation of having natively compileable code versus bytecode. Having readonly violations in runtime is not desireable: char[] s = "hello"; ... getting AV in the code far far away (and might be not always)... s[0] = 0; ... is not acceptable at all if you can prevent it by declaring readonly char[] s = "hello"; Again, this is not about 100% readonly protection. Some reasonable compromise but without delayed runtime checks please."Regan Heath" <regan netwin.co.nz> wrote in message news:opstg4vfvz23k2f5 nrage.netwin.co.nz...Yep.On Tue, 5 Jul 2005 16:30:50 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:Regan, general idea: if something could be done in compile time than it shall be done there.Attached is a classification table of results we've got on round III. Clearly there are just two types of constness proposed: 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.pdfThis 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). ReganAs you may see there is a penalty on runtime readonly checks ( <= 10% )Yep.- not good.You cannot say that, without first weighing the cost up with the benefit. The cost is ____? The benefit is ____? Therefore as cost < benefit, not good.Mea culpa, this number is about completely different stuff.As stated in first articlehttp://pag.csail.mit.edu/~mernst/pubs/ref-immutability-oopsla2004-slides.pdf this one?it is possible to prove immutability in "99.something %". I think it is enough.Where? I must have missed that bit.immutability is well known term introduced I believe in: Donald E. Knuth, The Art of Computer Programming: Fundamental Algorithms (Vol. 1), twenty years ago. I mean problem is well known and discussed too many times: "utter immutability" can be verified at some extent only in reasonable amount of compilation time and only for pure (abstract) languages. Again deep/shallow immutability is a term and has nothing common with probability of verification. E.g. language can have shallow immutability which can be staticly verifiable in 100% cases. Or cannot. Depends on implementation and language features like const_cast<> in C++.I even think that even 50% cases (shallow) in compile time will be extremely nice.Define "shallow", because obviously we have different definitions of what exactly it means. "deep" as used by Walter earlier appeared to me to mean "completely and utterly" as in the case where he used it, it guaranteed immutability essentially for the lifetime of the variable/data from all references.Page 16 in: http://www-sop.inria.fr/everest/events/cassis05/Transp/poll.pdf There it is about classes. I propose to use the same schema but only for arrays and pointers - do not propagate constness in depth. Such immutability can be easily verified on 100% and IMHO reasonable compromise. In fact D compiler already has everything in place to implement it. Andrew.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.Once you define "shallow" I'm sure I'll know what you mean, and I'll probably agree.
Jul 06 2005
Again deep/shallow immutability is a term and has nothing common with probability of verification. E.g. language can have shallow immutability which can be staticly verifiable in 100% cases. Or cannot. Depends on implementation and language features like const_cast<> in C++.not to beat a fairly-dead horse but const_cast<> is the least of the worries: char x; const char* y = &x; x = 'a'; With Walter's in proposal such code wouldn't be allowed but I wouldn't be surprised if the compiler would catch it. I think it would help to distinguish between a readonly view of a shared resource and an immutable resource.
Jul 06 2005
"Ben Hinkle" <bhinkle mathworks.com> wrote in message news:dahg5j$2t5v$1 digitaldaemon.com...Ben, I understand the intention. Theoretically such verification is possible but practically it is too complex task to consider it. In example you've provided variable is being aliases which immediately demands verification of not only write points but also all read points for each resource.Again deep/shallow immutability is a term and has nothing common with probability of verification. E.g. language can have shallow immutability which can be staticly verifiable in 100% cases. Or cannot. Depends on implementation and language features like const_cast<> in C++.not to beat a fairly-dead horse but const_cast<> is the least of the worries: char x; const char* y = &x; x = 'a'; With Walter's in proposal such code wouldn't be allowed but I wouldn't be surprised if the compiler would catch it.I think it would help to distinguish between a readonly view of a shared resource and an immutable resource.Yep. Excellent point. Walter is saying that control of immutabile resurces in C++ is impossible ( and he is right here ) so D does not need any immutability at all - not for immutable resources and not for immutable observers (const in C++). And latter corollary is causing dispute here. Immutable observers make real sense especially in context of D's arrays. D has the same notation for array (resource) and slice ( array observer ). And this situation highly demands notion of immutable observers - at least for arrays and pointers. Andrew.
Jul 06 2005
On Wed, 6 Jul 2005 15:34:17 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:"Ben Hinkle" <bhinkle mathworks.com> wrote in message news:dahg5j$2t5v$1 digitaldaemon.com...This is an important distinction I think many people might miss at first glace/read. You can have immutable data i.e. the original copy/source of the data is itself immutable. In this case it's impossible to have a mutable reference to that data as the data simply cannot be modified. You can have mutable data, and in that case mutable references to that data. But, you can also have an immutable reference to mutable data. So while the data may be mutable, it's not *via* an immutable reference. Something which causes confusion... The phrase "immutable reference" can be used to mean a reference which cannot change, or a reference to data which cannot change (I have used the latter above). The terms Andrew has used above: resource, observer etc are then useful to highlight the differences. An "observer" is an immutable reference, or to be clear "a reference which cannot be used to modify the data", it simply observes the data. A "resource" is the data itself. A "reference" is what we have currently, a reference which can be used to modify the data. ReganBen, I understand the intention. Theoretically such verification is possible but practically it is too complex task to consider it. In example you've provided variable is being aliases which immediately demands verification of not only write points but also all read points for each resource.Again deep/shallow immutability is a term and has nothing common with probability of verification. E.g. language can have shallow immutability which can be staticly verifiable in 100% cases. Or cannot. Depends on implementation and language features like const_cast<> in C++.not to beat a fairly-dead horse but const_cast<> is the least of the worries: char x; const char* y = &x; x = 'a'; With Walter's in proposal such code wouldn't be allowed but I wouldn't be surprised if the compiler would catch it.I think it would help to distinguish between a readonly view of a shared resource and an immutable resource.Yep. Excellent point. Walter is saying that control of immutabile resurces in C++ is impossible ( and he is right here ) so D does not need any immutability at all - not for immutable resources and not for immutable observers (const in C++). And latter corollary is causing dispute here. Immutable observers make real sense especially in context of D's arrays. D has the same notation for array (resource) and slice ( array observer ). And this situation highly demands notion of immutable observers - at least for arrays and pointers.
Jul 06 2005
An "observer" is an immutable reference, or to be clear "a reference which cannot be used to modify the data", it simply observes the data. A "resource" is the data itself. A "reference" is what we have currently, a reference which can be used to modify the data. ReganExactly!
Jul 06 2005
In article <dahg5j$2t5v$1 digitaldaemon.com>, Ben Hinkle says...I can still hear the horse whinnying, so I had to beat it some more (strong horse).. Maybe we are expecting too much functionality to start out with? Maybe by tightening the rules on what 'readonly' (ro) vars. can be and how they are used, we could at least get some what we want and have the compiler (with not un-reasonable effort) enforce this immutability so it meets Walter's criteria of having semantic value? For example, using Ben and Walter's earlier ideas and syntax: in, out and final (except the compiler would have to throw errors, not just warnings): - Assigning something to an 'ro' var. would demote the rvalue to readonly for the rest of that scope. That along with the rules below should cover the example for both pointers and implicit references. - After initialization, ro vars. can't be assigned to or dereferenced as an lvalue, i.e.: // Verboten because ro p, 'object' and 'arr' are derefenced *p = 10; object.member = x; arr[0][10] = y; - declaration and initialization of final locals would have to be in one statement so the compiler wouldn't have to keep track of if they have been initialized. - 'out' return values could only be assigned to a final var. - ro vars. can only be passed via an ro param. - The reference or cast operators couldn't be used on an ro rvalue. - Methods couldn't be called on ro objects - even including byval structs passed with 'in'. Member vars. could be an rvalue using the rules above. - Only ro arrays of value types or arrays of arrays could be used as the aggragate of foreach statements (other ro objects couldn't be the aggragate) and the value expression would have to be ro as well: void foo(in X[] arr) { foreach(in X x; arr){...} } - Value types could also be specified as ro. Maybe (probably) I'm forgetting something(s) and this already might seem pretty restrictive, but I'm guessing that we would find a lot of uses for even very tightly controlled ro vars. and the right set of rules would keep it from becoming a nightmare for compiler implementors. - DaveAgain deep/shallow immutability is a term and has nothing common with probability of verification. E.g. language can have shallow immutability which can be staticly verifiable in 100% cases. Or cannot. Depends on implementation and language features like const_cast<> in C++.not to beat a fairly-dead horse but const_cast<> is the least of the worries: char x; const char* y = &x; x = 'a'; With Walter's in proposal such code wouldn't be allowed but I wouldn't be surprised if the compiler would catch it. I think it would help to distinguish between a readonly view of a shared resource and an immutable resource.
Jul 08 2005
On Wed, 6 Jul 2005 13:29:15 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:Of course, I agree that CT const is better than RT const. However, if you're saying RT is useless, well.. If it's not possible to catch "a reasonable percentage" (I have no exact figures either) of cases with CT in D, then a RT solution that can catch the remaining cases may be of benefit. As I tried to suggest above, it's a cost-benefit equation.Obviously it is hard to provide numbers here. But motivation of doing constness solely in CT is the same as motivation of having natively compileable code versus bytecode.Regan, general idea: if something could be done in compile time than it shall be done there.Yep.As you may see there is a penalty on runtime readonly checks ( <= 10% )Yep.- not good.You cannot say that, without first weighing the cost up with the benefit. The cost is ____? The benefit is ____? Therefore as cost < benefit, not good.Having readonly violations in runtime is not desireable: char[] s = "hello"; ... getting AV in the code far far away (and might be not always)... s[0] = 0; ... is not acceptable at all if you can prevent it by declaring readonly char[] s = "hello";I agree. Using my idea the "readonly" above wouldn't be required, the original code would produce a readonly violation. The reason it would is that the readonly flag of the constant "hello" would be passed to "s" upon assignment (assuming we decide constant string literals are readonly).Again, this is not about 100% readonly protection. Some reasonable compromise but without delayed runtime checks please.That's your personal choice. I'm all for choice, which is why I suggested the runtime solution be optional, enabled/disabled by compile time flags etc. It's exactly comparable to array bounds checking and other DBC features disabled for release mode. In other words, if you dont want it, you wont use it. If I want it, I will use it. Everyone is happy.I am not confused about the definition of "immutable", just "shallow" and "deep" as I've seen them used in this thread (and others) several times by different people and they (apparently) meant different things in each case. eg. Walters use of "deep" compared to your use here for C++ (which we agree is different - yet both are called "deep"??)immutability is well known term introduced I believe in: Donald E. Knuth, The Art of Computer Programming: Fundamental Algorithms (Vol. 1), twenty years ago. I mean problem is well known and discussed too many times:I even think that even 50% cases (shallow) in compile time will be extremely nice.Define "shallow", because obviously we have different definitions of what exactly it means. "deep" as used by Walter earlier appeared to me to mean "completely and utterly" as in the case where he used it, it guaranteed immutability essentially for the lifetime of the variable/data from all references.Ok, so the definition of "shallow" is essentially: an object that cannot be modified directly, but may be modified by obtaining(or previously obtaining) a referece to one of the objects sub components (typically via a member function returning them). And "deep" is in turn what Walter described here: 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 which case my idea is "shallow" immutability with additional runtime DBC style "deep" immutability checks. A compromise if you will. ReganPage 16 in: http://www-sop.inria.fr/everest/events/cassis05/Transp/poll.pdf There it is about classes. I propose to use the same schema but only for arrays and pointers - do not propagate constness in depth. Such immutability can be easily verified on 100% and IMHO reasonable compromise. In fact D compiler already has everything in place to implement it.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.Once you define "shallow" I'm sure I'll know what you mean, and I'll probably agree.
Jul 06 2005
"Regan Heath" <regan netwin.co.nz> wrote in message news:opstilxzg823k2f5 nrage.netwin.co.nz...On Wed, 6 Jul 2005 13:29:15 -0700, Andrew Fedoniouk <news terrainformatica.com> wrote:Yes, there are cases when you need deep immutability. For example of how COW string type might be implemented if D would have opAssign/ctor/dtor for structs. It is a sort of deep immutability - DI with runtime checks. struct string { private struct data { int refcnt; int length; //chars go here char* chars() { return cast( char* ) (this + 1); } } private data* d; void opIndexAssign(char c, int idx) { if( d.refcnt != 0 ) d = copyData(d); // make unique buffer d.chars[idx] = c; } void opAssign(string s) // assuming opAssign is there { if( --d.refcnt == 0 ) delete d; // we were sole // owner of the data d = s.d; ++d.refcnt; // do not dup, just increase refcnt } { d = allocData(s); // famous dup } { return d.chars[0..d.length ]; // no dup } ~this() { if( --d.refcnt == 0 ) delete d; // determenistic memory // management } } Interesting observation: it is possible to implement allocData as an allocation out of GC memory space using malloc/free. In this case GC will not scan (?) string data so string intensive applications may benefit from this even further. of having such strings is not so high. It depends on particular use cases to be short. arrays/pointers and opAssign/ctor/dtor then anyone can consider D as a full superset of C++ and Java together - feature complete state. And keeping in mind that D already has better templates, clean grammar and other nice features then D v.1.0 will be really the Thing. Andrew.Of course, I agree that CT const is better than RT const. However, if you're saying RT is useless, well.. If it's not possible to catch "a reasonable percentage" (I have no exact figures either) of cases with CT in D, then a RT solution that can catch the remaining cases may be of benefit. As I tried to suggest above, it's a cost-benefit equation.Obviously it is hard to provide numbers here. But motivation of doing constness solely in CT is the same as motivation of having natively compileable code versus bytecode.Regan, general idea: if something could be done in compile time than it shall be done there.Yep.As you may see there is a penalty on runtime readonly checks ( <= 10% )Yep.- not good.You cannot say that, without first weighing the cost up with the benefit. The cost is ____? The benefit is ____? Therefore as cost < benefit, not good.Having readonly violations in runtime is not desireable: char[] s = "hello"; ... getting AV in the code far far away (and might be not always)... s[0] = 0; ... is not acceptable at all if you can prevent it by declaring readonly char[] s = "hello";I agree. Using my idea the "readonly" above wouldn't be required, the original code would produce a readonly violation. The reason it would is that the readonly flag of the constant "hello" would be passed to "s" upon assignment (assuming we decide constant string literals are readonly).Again, this is not about 100% readonly protection. Some reasonable compromise but without delayed runtime checks please.That's your personal choice. I'm all for choice, which is why I suggested the runtime solution be optional, enabled/disabled by compile time flags etc. It's exactly comparable to array bounds checking and other DBC features disabled for release mode. In other words, if you dont want it, you wont use it. If I want it, I will use it. Everyone is happy.I am not confused about the definition of "immutable", just "shallow" and "deep" as I've seen them used in this thread (and others) several times by different people and they (apparently) meant different things in each case. eg. Walters use of "deep" compared to your use here for C++ (which we agree is different - yet both are called "deep"??)immutability is well known term introduced I believe in: Donald E. Knuth, The Art of Computer Programming: Fundamental Algorithms (Vol. 1), twenty years ago. I mean problem is well known and discussed too many times:I even think that even 50% cases (shallow) in compile time will be extremely nice.Define "shallow", because obviously we have different definitions of what exactly it means. "deep" as used by Walter earlier appeared to me to mean "completely and utterly" as in the case where he used it, it guaranteed immutability essentially for the lifetime of the variable/data from all references.Ok, so the definition of "shallow" is essentially: an object that cannot be modified directly, but may be modified by obtaining(or previously obtaining) a referece to one of the objects sub components (typically via a member function returning them). And "deep" is in turn what Walter described here: 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 which case my idea is "shallow" immutability with additional runtime DBC style "deep" immutability checks. A compromise if you will.Page 16 in: http://www-sop.inria.fr/everest/events/cassis05/Transp/poll.pdf There it is about classes. I propose to use the same schema but only for arrays and pointers - do not propagate constness in depth. Such immutability can be easily verified on 100% and IMHO reasonable compromise. In fact D compiler already has everything in place to implement it.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.Once you define "shallow" I'm sure I'll know what you mean, and I'll probably agree.
Jul 06 2005
class xxx {
static active_cnt = 0;
void xxx ( char[] setup_parm ) {
do_something(setup_parm);
++active_cnt;
);
..
}
int main ( char[][] args )
{
xxx one = new xxx("whoop dee doo");
deepconst xxx* ref = &one;
// is it now impossible to create any more instances of xxx?
bool never = true;
return never;
}
Jul 11 2005