www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - To mutate or not to mutate?

reply Matthias Spycher <matthias coware.com> writes:
http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

Does anyone else (Kris?) feel an urgent need for some immutable basic 
data types in D? Especially in light of the recent plan to translate SWT 
-> DWT and possible other Java projects in the future. IMHO D should at 
least provide immutable strings. I'm sure we all agree -- it has been 
discussed before -- that having some light-weight immutable data types 
is a good thing in the context of scalable, multi-threaded, GC-enabled 
programs. Now it just seems more urgent...

Kris, I imagine your translator will be dependent not on just the D 
language, but also a library, right? If so, which one?

Matthias
Feb 08 2006
next sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Matthias Spycher" <matthias coware.com> wrote in message 
news:dsdc9n$20dh$1 digitaldaemon.com...

 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic data 
 types in D? Especially in light of the recent plan to translate SWT -> DWT 
 and possible other Java projects in the future. IMHO D should at least 
 provide immutable strings. I'm sure we all agree -- it has been discussed 
 before -- that having some light-weight immutable data types is a good 
 thing in the context of scalable, multi-threaded, GC-enabled programs. Now 
 it just seems more urgent...


The problem with some sort of immutable data type is there are at least a 
dozen different ways to do it. A lot more thinking has to go into this, less 
we get stuck with a poor design like C++'s.
Feb 08 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 


Definately.  While I find the idea appealing, I would prefer to approach 
it carefully.  Particularly since the more straightforward approaches 
(such as making 'const' a logical qualifier) seem likely to break a 
tremendous amount of code in ways that might not be so easy to fix.


Sean
Feb 08 2006
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsdn6t$289j$3 digitaldaemon.com...

 "Matthias Spycher" <matthias coware.com> wrote in message 
 news:dsdc9n$20dh$1 digitaldaemon.com...

 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic 
 data types in D? Especially in light of the recent plan to translate 
 SWT -> DWT and possible other Java projects in the future. IMHO D should 
 at least provide immutable strings. I'm sure we all agree -- it has been 
 discussed before -- that having some light-weight immutable data types is 
 a good thing in the context of scalable, multi-threaded, GC-enabled 
 programs. Now it just seems more urgent...


 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, 
 less we get stuck with a poor design like C++'s.


I would rise this question again:

Is it possible to declare (typedef) new array type with all mutating methods 
disabled?
Sort of:
typedef char[] string ( no opIndexAssign; no void length(int) )

This will be pretty sufficient for strings and other cases.
In any case ability to create new types from intrinsic types is a good thing 
in D.
But it is a half. It should be a mechanism of declaring also set of 
operations allowed.

Again, array as a builtin feature lacks their immutable counterparts in D 
typesystem.

Andrew.
Feb 08 2006
parent reply Sean Kelly <sean f4.ca> writes:
Andrew Fedoniouk wrote:

 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:dsdn6t$289j$3 digitaldaemon.com...

 "Matthias Spycher" <matthias coware.com> wrote in message 
 news:dsdc9n$20dh$1 digitaldaemon.com...

 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic 
 data types in D? Especially in light of the recent plan to translate 
 SWT -> DWT and possible other Java projects in the future. IMHO D should 
 at least provide immutable strings. I'm sure we all agree -- it has been 
 discussed before -- that having some light-weight immutable data types is 
 a good thing in the context of scalable, multi-threaded, GC-enabled 
 programs. Now it just seems more urgent...


 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, 
 less we get stuck with a poor design like C++'s.


 
 I would rise this question again:
 
 Is it possible to declare (typedef) new array type with all mutating methods 
 disabled?
 Sort of:
 typedef char[] string ( no opIndexAssign; no void length(int) )
 
 This will be pretty sufficient for strings and other cases.


const char[] ar = "hello world";
char* c = &ar[0];
c = 'j';

I grant that it's a corner case, but worth noting nevertheless.


Sean
Feb 08 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I would rise this question again:

 Is it possible to declare (typedef) new array type with all mutating 
 methods disabled?
 Sort of:
 typedef char[] string ( no opIndexAssign; no void length(int) )

 This will be pretty sufficient for strings and other cases.


 const char[] ar = "hello world";
 char* c = &ar[0];
 c = 'j';

 I grant that it's a corner case, but worth noting nevertheless.


In C++ I am enabling:
  T operator []
and disabling:
   T& operator []
in such cases.

But as you said "it's a corner case".

cast() is there and you may
do scarry things with it and this is not an argument to disable raw cast in 
the language, right?

Andrew.
Feb 08 2006
prev sibling next sibling parent Matthias Spycher <matthias coware.com> writes:
I agree, it's not an easy task in general. But a simple final String 
class that prevents (as much as possible) all direct access to the 
underlying array of characters in its API would go a long way already, 
no? If the API exposed only dchar values (for accessing individual 
characters), you would not expose the actual implementation, which might 
be optimized during construction.

Immutability implies sharing, so these objects are more likely to be 
allocated on the heap, and I imagine the garbage collector could provide 
an interning service for them.

The implementation of java.lang.String has evolved quite a bit over the 
years, despite the fact that it deals with only one type of char. I 
don't expect the evolution of a D.String to be any different. Certainly, 
having minimal support for immutable strings in D 1.0 has to be better 
than no support at all.

Matthias

Walter Bright wrote:

 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s.
Feb 08 2006
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
I'd like to add that from my 6 years with C++, I have never been _saved_ (
to my knowledge -- knock on wood ) by const.  And I must have typed it
thousands of times .

Not that Im voting against immutability, only that if it does get added its
as non-intrusive as possible.  But I really don't want to start another
debate!

Charlie

"Walter Bright" <newshound digitalmars.com> wrote in message
news:dsdn6t$289j$3 digitaldaemon.com...

 "Matthias Spycher" <matthias coware.com> wrote in message
 news:dsdc9n$20dh$1 digitaldaemon.com...

 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic




data

 types in D? Especially in light of the recent plan to translate SWT ->




DWT

 and possible other Java projects in the future. IMHO D should at least
 provide immutable strings. I'm sure we all agree -- it has been




discussed

 before -- that having some light-weight immutable data types is a good
 thing in the context of scalable, multi-threaded, GC-enabled programs.




Now

 it just seems more urgent...


 The problem with some sort of immutable data type is there are at least a
 dozen different ways to do it. A lot more thinking has to go into this,


less

 we get stuck with a poor design like C++'s.
Feb 09 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Charles" <noone nowhere.com> wrote in message 
news:dsfnlr$247h$1 digitaldaemon.com...

 I'd like to add that from my 6 years with C++, I have never been _saved_ (
 to my knowledge -- knock on wood ) by const.  And I must have typed it
 thousands of times .

 Not that Im voting against immutability, only that if it does get added 
 its
 as non-intrusive as possible.  But I really don't want to start another
 debate!


Well it is different point of view and it is perfectly valid. For you and 
for me.

The thing is simple: const is a declartion - meta information if you wish.
const is more collaborative tool than probably anything else.

It is seems like for Walter too - const worth nothing because he is working
on his own codebase and he knows *his own* code very well.

But we have completely different story in team projects.

See, partner developers from China will send us class:

class Record
{
    Field[] fields();
}

Do you have any idea of how you can use this fields?
Can you change fieldset or not?

Again, for a lone-code-wolf writing 50000 lines code in three months
const is (probably) just nothing if not worse - more chars to type.

For the team it is a way to reduce needed documentation for example - quite
opposite to your situation.

C++ and C99 has "char[]" and "const char[]" which are  two distinct types.

D has only one char[]. Step back? Yes.


to reduce problem significantly. For classes and objects you can create
readonly envelopes, but arrays are naked in this regard.

You can create as many meta programming features as you wish but
without such basic feature your type system is just


Andrew.
Feb 09 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Andrew Fedoniouk wrote:

 
 For the team it is a way to reduce needed documentation for example - quite
 opposite to your situation.
 
 C++ and C99 has "char[]" and "const char[]" which are  two distinct types.


Frankly, I have far more problems with people just not writing 
meaningful code.  For example:

class C {
public:
     Thing* getThing();
};

Who owns the Thing returned by C?  And is Thing even dynamically 
allocated?  auto_ptr was designed for this purpose, but no seems to use 
it correctly:

class C {
public:
     std::auto_ptr<Thing> getThing();
};

Here, the transferral of ownership indicated by the syntax, as is the 
fact that Thing was allocated on the heap.

The same could be said of const qualifiers.  In my experience, little 
thought often goes into what is made 'const' and what isn't, and 
deciphering this later is a maintenance nightmare.  Pointers are another 
problem area, as many people don't seem aware that "int const *const" is 
a legal statement, or know what the position of each 'const' implies.

In summary, I agree that 'const' can be useful in Ivory Tower type 
programming.  But unfortunately, I seem to keep being called out to the 
docks.  If someone can come up with a form of immutability that is both 
elegant and meaningful I'll be cheering for its inclusion in D.  But I'm 
beginning to agree with Walter that the C++ implementation can 
deceptive, which greatly reduces its utility.


Sean
Feb 09 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:dsgie6$2lap$1 digitaldaemon.com...

 Andrew Fedoniouk wrote:

 For the team it is a way to reduce needed documentation for example - 
 quite
 opposite to your situation.

 C++ and C99 has "char[]" and "const char[]" which are  two distinct 
 types.


 Frankly, I have far more problems with people just not writing meaningful 
 code.  For example:

 class C {
 public:
     Thing* getThing();
 };

 Who owns the Thing returned by C?  And is Thing even dynamically 
 allocated?  auto_ptr was designed for this purpose, but no seems to use it 
 correctly:

 class C {
 public:
     std::auto_ptr<Thing> getThing();
 };


Let's say you need to create bullet-proof library of the things
Then it is just enough to declare:

class Thing
{
    package ~this();
}

Having this no one  auto_ptr will accept it and user will
get an idea that this Thing is managed by Things package.
No documentation needed and compiler will enforce this.


 Here, the transferral of ownership indicated by the syntax, as is the fact 
 that Thing was allocated on the heap.


Yep, "Show me your destructor and I will tell you what policy do you use"


 The same could be said of const qualifiers.  In my experience, little 
 thought often goes into what is made 'const' and what isn't, and 
 deciphering this later is a maintenance nightmare.  Pointers are another 
 problem area, as many people don't seem aware that "int const *const" is a 
 legal statement, or know what the position of each 'const' implies.


I understand that this const * (const *) notation in C++ is just a ... you 
know what.
Trust me, I understand Walter's concerns and know them too well.


 In summary, I agree that 'const' can be useful in Ivory Tower type 
 programming.  But unfortunately, I seem to keep being called out to the 
 docks.  If someone can come up with a form of immutability that is both 
 elegant and meaningful I'll be cheering for its inclusion in D.  But I'm 
 beginning to agree with Walter that the C++ implementation can deceptive, 
 which greatly reduces its utility.


Let me remind that idea of "practical immutability" again:

1) Now in D any user type (structure, class) can be designed to be explictly 
immutable -
    if you want some class of the package be immutable outside - declare
    all its mutating methods with package attribute. Simple and is already 
there.

2) arrays.  array is a builtin *structure* in D with its own set of 
operations:
    There is no mechanism in D to declare readonly array.

                      b) -or- provide  another way (e.g. extended typedef)
                           to explicily list operations allowed on the array 
type.

3) pointers. The same problem and similar solution:


    so *rop cannot serve l-value purposes.

Implementation is simple, notation is simple - can be implemented reliably.



Andrew Fedoniouk.
http://terrainformatica.com
Feb 09 2006
prev sibling parent Matthias Spycher <matthias coware.com> writes:
As much as I like the notion of immutable arrays, it is a tough 
proposition in a language that directly exposes memory to the programmer 
using pointers.

For an object-oriented language with a GC, I would propose a class-based 
solution for immutable objects. They are good candidates for sharing, so 
allocation on the heap will be frequent. In other words, the class 
overhead is justifiable.

I think I'm on Walter's side regarding const; also for simplicity's sake.

Matthias

Andrew Fedoniouk wrote:

 "Charles" <noone nowhere.com> wrote in message 
 news:dsfnlr$247h$1 digitaldaemon.com...

 I'd like to add that from my 6 years with C++, I have never been _saved_ (
 to my knowledge -- knock on wood ) by const.  And I must have typed it
 thousands of times .

 Not that Im voting against immutability, only that if it does get added 
 its
 as non-intrusive as possible.  But I really don't want to start another
 debate!


 
 Well it is different point of view and it is perfectly valid. For you and 
 for me.
 
 The thing is simple: const is a declartion - meta information if you wish.
 const is more collaborative tool than probably anything else.
 
 It is seems like for Walter too - const worth nothing because he is working
 on his own codebase and he knows *his own* code very well.
 
 But we have completely different story in team projects.
 
 See, partner developers from China will send us class:
 
 class Record
 {
     Field[] fields();
 }
 
 Do you have any idea of how you can use this fields?
 Can you change fieldset or not?
 
 Again, for a lone-code-wolf writing 50000 lines code in three months
 const is (probably) just nothing if not worse - more chars to type.
 
 For the team it is a way to reduce needed documentation for example - quite
 opposite to your situation.
 
 C++ and C99 has "char[]" and "const char[]" which are  two distinct types.
 
 D has only one char[]. Step back? Yes.
 

 to reduce problem significantly. For classes and objects you can create
 readonly envelopes, but arrays are naked in this regard.
 
 You can create as many meta programming features as you wish but
 without such basic feature your type system is just
 
 
 Andrew.
Feb 09 2006
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Wed, 8 Feb 2006 13:10:19 -0800, Walter Bright wrote:


 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s.


This is an encouraging response, Walter. Previously I was under the
distinct impression that the whole idea of having the D language help
coders deal with concept of immutable data was against your philosophy.
This note of yours seems to be saying that you can see it happening in D,
but only after the right amount of thinking about 'how to do it well' has
occurred.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
10/02/2006 10:09:47 AM
Feb 09 2006
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Walter Bright wrote:

 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 
 
 


Can someone tell more about what's wrong and/or what could be better 
with C++'s design(const)?


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Feb 10 2006
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <dsil1d$1gs8$1 digitaldaemon.com>, Bruno Medeiros says...

Walter Bright wrote:

 
 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, less 
 we get stuck with a poor design like C++'s. 
 
 


Can someone tell more about what's wrong and/or what could be better 
with C++'s design(const)?


The issue is quite subjective.  It depends on what you consider 'wrong'.

IMHO, const appears to be the way most of to many developers because that's what
its for.  By its very nature, it is purposefully designed to make your life
harder all in the name of data integrity.

Now how it accomplishes that job and wether or not its doing it well is totally
up to debate.  Personally, I find API authors abusing 'const' nearly as much as
API users abusing 'const_cast' so its kind of a toss-up.

---------------

As for D: if there was some way to impose the COW idiom on assigning from const
to non-const, then I think we'd have a superior solution.  At a minimum this
would require const to only apply to primitive/scalar types which seems
acceptable: classes and structs at least have a way to protect their internals
via methods.

I'd also like to see 'readonly' used in favor of 'const'.  A 'writable' modifier
would also make template programming easier, due to its symmetry (see below)


 // to summarize the above:

 readonly char[] x = "hello world";
 char[] y = cast(char[])x; // Explicit cast from readonly triggers COW idiom
 
 y[0..$] = "byebye world"; // legal (working with a copy of x)
 x[0..$] = "byebye world"; // illegal (readonly)
 
 readonly Foobar a = new Foobar(); // illegal: readonly not applicable to
classes
 
 // example of using 'writable' (spoof of the ol' const-cast)
 template(writable T) const_cast{
   T foobar(readonly T arg){
     return cast(writable)arg;
   }
 }


- Eric Anderton at yahoo
Feb 10 2006
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I'd also like to see 'readonly' used in favor of 'const'.  A 'writable' 
 modifier
 would also make template programming easier, due to its symmetry (see 
 below)


 // to summarize the above:

 readonly char[] x = "hello world";
 char[] y = cast(char[])x; // Explicit cast from readonly triggers COW 
 idiom

 y[0..$] = "byebye world"; // legal (working with a copy of x)
 x[0..$] = "byebye world"; // illegal (readonly)

 readonly Foobar a = new Foobar(); // illegal: readonly not applicable to 
 classes

 // example of using 'writable' (spoof of the ol' const-cast)
 template(writable T) const_cast{
   T foobar(readonly T arg){
     return cast(writable)arg;
   }
 }




Exactly.

Thought about decorations:

In phrase 'readonly char[]'  readonly is in fact a part of array type 
modifier ([])
so semanticly speaking it should look like 'char readonly []' -


Second one about "Explicit cast from readonly triggers COW idiom"

I think that cast should be a cast as it is now.
dup is already there for that purposes. No?

Andrew.
Feb 11 2006
parent reply pragma <pragma_member pathlink.com> writes:
In article <dsk7ch$qmm$1 digitaldaemon.com>, Andrew Fedoniouk says...

 I'd also like to see 'readonly' used in favor of 'const'.  A 'writable' 
 modifier
 would also make template programming easier, due to its symmetry (see 
 below)


 // to summarize the above:

 readonly char[] x = "hello world";
 char[] y = cast(char[])x; // Explicit cast from readonly triggers COW 
 idiom

 y[0..$] = "byebye world"; // legal (working with a copy of x)
 x[0..$] = "byebye world"; // illegal (readonly)

 readonly Foobar a = new Foobar(); // illegal: readonly not applicable to 
 classes

 // example of using 'writable' (spoof of the ol' const-cast)
 template(writable T) const_cast{
   T foobar(readonly T arg){
     return cast(writable)arg;
   }
 }




Exactly.

Thought about decorations:

In phrase 'readonly char[]'  readonly is in fact a part of array type 
modifier ([])
so semanticly speaking it should look like 'char readonly []' -


Second one about "Explicit cast from readonly triggers COW idiom"

I think that cast should be a cast as it is now.
dup is already there for that purposes. No?


I disagree.  Readonly means more than "don't assign to me".  It should also
mean, "the data I point to is protected".  Sure, you could emulate this with a
dup but its much cleaner if it is an assumed operation when casting to and from
readonly*.

One of the pitfalls of the C's const design was that the best that could
possibly be accomplished by the complier is a static cast.  In D, we have a
garbage collector, so we can automatically enforce the readonly integrity of the
original const data by performing a copy on cast.  This will lead to fewer
errors and make things more failsafe by strictly maintaining readonly and
writable sets of data.**


in the way you suggest makes D's syntax context-sensitive; something that Walter
has been quite adamant about avoiding.  For instance, how would you expect the
following to compile?


 char



IMO, we're better off using no-nonsense modifiers like 'readonly' and
'writeable' as there's zero room to debate what they actually mean, or how to
parse them.

* Casting from writable to readonly should also copy as to ensure that writable
and readable data remain distinct and protected.  I'd anticipate that .dup on
array operations would also inherit the parent's readonly/writable attributes,
so slices would have to be cast in a similar way.  This would ensure that
aliases to readonly data would in themselves be readonly.

** Of course you can always throw caution to the wind by casting through void*,
which would avoid any copying by not explicitly casting to/from readonly.

- Eric Anderton at yahoo
Feb 11 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:dskoas$1u2n$1 digitaldaemon.com...

 In article <dsk7ch$qmm$1 digitaldaemon.com>, Andrew Fedoniouk says...

 I'd also like to see 'readonly' used in favor of 'const'.  A 'writable'
 modifier
 would also make template programming easier, due to its symmetry (see
 below)


 // to summarize the above:

 readonly char[] x = "hello world";
 char[] y = cast(char[])x; // Explicit cast from readonly triggers COW
 idiom

 y[0..$] = "byebye world"; // legal (working with a copy of x)
 x[0..$] = "byebye world"; // illegal (readonly)

 readonly Foobar a = new Foobar(); // illegal: readonly not applicable 
 to
 classes

 // example of using 'writable' (spoof of the ol' const-cast)
 template(writable T) const_cast{
   T foobar(readonly T arg){
     return cast(writable)arg;
   }
 }




Exactly.

Thought about decorations:

In phrase 'readonly char[]'  readonly is in fact a part of array type
modifier ([])
so semanticly speaking it should look like 'char readonly []' -


Second one about "Explicit cast from readonly triggers COW idiom"

I think that cast should be a cast as it is now.
dup is already there for that purposes. No?


 I disagree.  Readonly means more than "don't assign to me".  It should 
 also
 mean, "the data I point to is protected".  Sure, you could emulate this 
 with a
 dup but its much cleaner if it is an assumed operation when casting to and 
 from
 readonly*.

 One of the pitfalls of the C's const design was that the best that could
 possibly be accomplished by the complier is a static cast.  In D, we have 
 a
 garbage collector, so we can automatically enforce the readonly integrity 
 of the
 original const data by performing a copy on cast.  This will lead to fewer
 errors and make things more failsafe by strictly maintaining readonly and
 writable sets of data.**


Ideally yes, but practically you *will* have situations
when you need to remove 'constness' from particular readonly
data chunk - for example - passing string to some external API and 
libraries.

The whole idea of having readonly arrays/pointers - provide
declarative readonliness but keep implementation effective as it is.


So instead of:

readonly char[] x = "hello world";
char[] y = cast(char[])x; // Explicit cast from readonly triggers COW

you will write:

readonly char[] x = "hello world";
char[] y = x.dup; // Explicit copy

- more clear I believe.



 Using it
 in the way you suggest makes D's syntax context-sensitive; something that 
 Walter
 has been quite adamant about avoiding.  For instance, how would you expect 
 the
 following to compile?


 char



 IMO, we're better off using no-nonsense modifiers like 'readonly' and
 'writeable' as there's zero room to debate what they actually mean, or how 
 to
 parse them.



D tokenizer is already doing this stuff everywhere.
!  and !=  , < and <=, + and ++, etc.



 * Casting from writable to readonly should also copy as to ensure that 
 writable
 and readable data remain distinct and protected.  I'd anticipate that .dup 
 on
 array operations would also inherit the parent's readonly/writable 
 attributes,
 so slices would have to be cast in a similar way.  This would ensure that
 aliases to readonly data would in themselves be readonly.


Runtime and compiler has no way to enforce "data remain distinct and 
protected"
in 100%.

The *only* thing what compiler can verify and enforce is that:

    particular readonly pointer has no operartion "l-value dereferencing"

The same apply to readonly arrays.

It is a task of the same complexity for compiler as to determine if class 
Foo
has method Bar - not more.

Other meanings of const and readonly, is a pitty, but just dreams.


 ** Of course you can always throw caution to the wind by casting through 
 void*,
 which would avoid any copying by not explicitly casting to/from readonly.


Andrew.
Feb 11 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:dsil1d$1gs8$1 digitaldaemon.com...

 Walter Bright wrote:

 The problem with some sort of immutable data type is there are at least a 
 dozen different ways to do it. A lot more thinking has to go into this, 
 less we get stuck with a poor design like C++'s.


 Can someone tell more about what's wrong and/or what could be better with 
 C++'s design(const)?


"const" has many possible meanings:

1) is the data immutable and set at compile time, so it could be put in ROM?
2) is the pointer itself const, or is the data it points to const?
3) does const mean write-once, i.e. can it be initialized at runtime?
4) can other references to the same data change it?
5) can "constness" be cast away?
6) if one has a "const" array of objects, is the array reference const, the 
array contents const, or are the object contents const? What about what 
those objects refer to?
7) what about "logical" constness, where data can appear to be constant but 
has, in actuallity, "mutable" state? (see C++ "mutable" keyword)

And, of course, every combination of the above.
Feb 10 2006
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dsjq1j$5rv$2 digitaldaemon.com...

 "Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
 news:dsil1d$1gs8$1 digitaldaemon.com...

 Walter Bright wrote:

 The problem with some sort of immutable data type is there are at least 
 a dozen different ways to do it. A lot more thinking has to go into 
 this, less we get stuck with a poor design like C++'s.


 Can someone tell more about what's wrong and/or what could be better with 
 C++'s design(const)?


 "const" has many possible meanings:

 1) is the data immutable and set at compile time, so it could be put in 
 ROM?
 2) is the pointer itself const, or is the data it points to const?


In C/C++ declaration of const pointer is like this:

const typename *  -or-
typename const *

this is just bad - two tokens used in arbitrary order (who invented this?) 
for declaration of const-ptr.





 3) does const mean write-once, i.e. can it be initialized at runtime?




means that in scope of function foo
 '*p' cannot be an l-value.


 4) can other references to the same data change it?


yes.


 5) can "constness" be cast away?


yes. cast is a brute force and last resort but usable. Even Prof. Niklaus 
Wirth agree with this.


 6) if one has a "const" array of objects, is the array reference const, 
 the array contents const, or are the object contents const? What about 
 what those objects refer to?





content of the array's raw data (in range ptr...ptr+length )
and pseudo fields ptr and length cannot be changed.





 7) what about "logical" constness, where data can appear to be constant 
 but has, in actuallity, "mutable" state? (see C++ "mutable" keyword)


This is not applicable in D. All objects (instances of some class) are 
mutable
by definition.


 And, of course, every combination of the above.


Well, not too much left.
The only problem I see is what to do
with structures:

struct myst
{
   int a;
   void m(int b) {  a = b; }
}


myst ms = ...;

I think this would be enough:

pms.a = 1; // compile time error - attempt to modify data at location 
pointed by readonly pointer.
- but -
pms.m(2); // is fine - author of the type provided explicit mutator.

ms = *pms; // is fine - creation of local copy of the variable with
                    // possible modification of that copy.

Andrew Fedoniouk.
http://terrainformatica.com
Feb 10 2006
prev sibling parent "Kris" <fu bar.com> writes:
"Matthias Spycher" <matthias coware.com> wrote...

 http://www-128.ibm.com/developerworks/java/library/j-jtp02183.html

 Does anyone else (Kris?) feel an urgent need for some immutable basic data 
 types in D? Especially in light of the recent plan to translate SWT -> DWT 
 and possible other Java projects in the future. IMHO D should at least 
 provide immutable strings. I'm sure we all agree -- it has been discussed 
 before -- that having some light-weight immutable data types is a good 
 thing in the context of scalable, multi-threaded, GC-enabled programs. Now 
 it just seems more urgent...


Mango has a number of immutable and pseudo-immutable classes (you can still 
bork the latter type given the lack of compiler support). It turns out that 
they're not actually needed for SWT ~ not even mango.text.String. While I 
agree that support for immutability should probably be a pre-requisite for a 
language that claims to support concurrency, Walter clearly feels it's 
pretty low on the priority list. We can but hope it will arrive in due time 
<g>


 Kris, I imagine your translator will be dependent not on just the D 
 language, but also a library, right? If so, which one?


Mango!
Feb 08 2006