"Regan Heath" <regan@netwin.co.nz> wrote in message news:opst1a3xe123k2f5@nrage.netwin.co.nz...
> On Sat, 16 Jul 2005 20:54:02 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>>>> and:
>>>>
>>>>     foo(data.dup);
>>>
>>> Not certain, foo might be:
>>>   foo(inout char[] param);
>>>
>>> right? you can't tell at this stage.
>>
>> Don't dup here since foo will dup if it needs to. You are probably assuming that foo will change param
>
> No, I was simply saying if you look at "foo(data.dup)" you do not know if the param is "in" or "inout". That piece of info would tell you if the function was *intending* to modify the param or not. However if it was "in" and thus not intending to modify the param it still might, accidently (bug) or illegally (bug, the programmer forgot the inout)

I understand.

>> but if foo does not obey COW it will document it
>
> How?

in it's documentation :-) The stuff that says what foo actually does. I think it's unusual to call a function without knowing what it does :-P

>> so that you can dup even with foo(char[] param). For example the
>> std.stream.Stream.readLine(char[] buffer) takes a regular char[] input
>> and
>> documents that it will fill the buffer without dup'ing. That is, it
>> explicitly tells the user it does not use COW.
>
> I dislike this and view it as wrong. The function declaration IMO should be "std.stream.Stream.readLine(inout char[] buffer)"

My complaint(s) with marking buffer as inout are:
1) it means the following code is illegal
  char[80] buf;
  char[] res = stdin.readLine(buf);
it errors since buf is a static array and 'inout char[]' requires an lvalue
dynamic array
2) it mistakenly gives the impression that in the code
  char[] buf = new char[80];
  char[] res = stdin.readLine(buf);
if the buffer wasn't big enough it would be resizes and the variable buf
would be modified (not the array contents - the actual variable 'buf'). In
fact what readLine does (and I argue should do no matter what happens with
const/etc) is it returns the actual array ptr and length and leaves the
input buffer variable refering to the original buffer.

>> ps - yes, Andrew, I know that if the author of foo forgot to mention the fact that it didn't obey COW that it would step on param so you don't have to post :-)
>
> Mistakes, those things we are trying to reduce, wouldn't it be nice if the
> compiler helped a little here?
> Some sort of enforcement of readonly for "in" would reduce errors at
> little or no cost as far as I can see.

No-one is saying it wouldn't be nice. The question is what, if anything, would balance all the pluses and minuses.

>>> Further the data referenced by the 'data' array can be modified in this
>>> function:
>>>   foo(char[] param);
>>>
>>> It is not 'readonly' only the array is, right?
>>
>> Can you give a more concrete example?
>
> void foo(char[] param) { param[0] = 'a'; }
>
>> If foo changes "data" then it should document that.
>
> Definately, the *compiler* should point out this error.

that's what some people say and, by the way, what dlint generates a warning for (at least it does for me - I don't think I've updated the zip file on my web site yet since I haven't rebuilt in Linux lately)

>> COW doesn't apply to functions that explicitly say they don't obey COW (not surprisingly).
>
> Not sure what you mean here, does "void foo(char[] param)" "explicitly say" it doesn't obey COW? I don't think it says anything WRT to COW. What it says to me is that it will *read* and not *modify* the parameter I pass it, however I *know* that is not guaranteed currently.
>
> Of course, you're reffering to documentation at this point. Wouldn't it be
> nicer if the information was a requirement of the function declaration,
> which IMO it could/would be if:
>  - in was readonly and enforced
>
> thus requring the above function to be "void foo(inout char[] param)" or for the modification to be removed, thus correcting the *bug* in the function.
>
>> If a function doesn't say it disobeys COW then D programmers are free to assume it obeys COW - that's "the D way".
>
> Which is 'nice' but hardly comforting if you're looking for the *bug* that mutates some of your data *somewhere* in a large program. All I'm saying is that it would be *nice* to have some help ensuring we (and others) use COW correctly.
>
> An ideal like COW is good, having no support in holding to that ideal is not good. IMO. To be clear I am not questioning the ideal, I *like* this ideal. The problem is not the ideal itself it's the support we have for that ideal.

Yeah - sure it would be nice but it isn't a no-brainer. The arguments have been made back and forth so many times I won't even bother. I really think this horse is good and dead.

> Forgive me that drastic formulation, but COW "the D way" (documentation
> only,
> no concept of ownership, auto_ptr ...) simply stinks. It's unsafe, why the
> heck not stick with C programming if that's all that D proponents have to
> say about this vital question? Don't get me wrong: D _is_ definitely a
> very
> exciting language! I simply don't get how you (Ben, Walter, many others
> ...)
> can be pleased with that "gentleman's agreement" esprit of COW that is
> currently
> called for "save" D programming. Experience shows that it doesn't work in
> the
> real world, and as much as I hate C++, I'd say that even the C++
> const "solution" offers much more than your COWBGA (COW by gentleman's
> agreement).

cowabunga - I love it!
Anyway, I trust Walter will come up with a solution that satisfies everyone.
:-) It is interesting how D might end up being C++ + Java + C# + ...
I feel for Walter since probably when he started D it was a much smaller
goal. If I were him I wouldn't hesitate to remove parts he feels are bloat
now (like bit arrays and length/$ or whatever it ended up as)
I've always felt like COW is much simpler than the alternative and, being
simpler, is much harder to mess up. Say "const" (with the standard caveats
about casting and aliasing) to a new programmer and watch the eyes glaze
over.

> No personal offense intended, just upset ...

no problem. no offense taken.

>
> Peace,
> Carlos
>
> 

Carlos wrote:

 I simply don't get how you (Ben, Walter, many others ...)
> can be pleased with that "gentleman's agreement" esprit of COW that is currently
> called for "save" D programming. Experience shows that it doesn't work in the
> real world, and as much as I hate C++, I'd say that even the C++ const "solution" offers much more than your COWBGA (COW by gentleman's
> agreement).
> 

And, I simply don't understand why this is such an issue.

Immutables are:

A. Worthless as an optimization. Optimization is context dependent.
B. Not a memory management tool, which is what auto_ptr is typically used for.  D has memory management, its not needed.
C. Defeatable in any case(without explicit hardware support) unless you remove all pointers from the language.

So it basically just comes down to a lint-like check on parameters and a new set of type modifiers to keep track of when coding.  If there is something else what is it?

You can currently make immutable objects. You can currently make immutable collections. But wait lets make the language twice as complex to implement so you don't have to!  C# doesnt have it, but business won't adopt it until D does!!

Given the other features of D, it is snake oil.  It looks good held up to the light, but does very little when applied.

This probably sounds a bit strong, but you guys talk about const like the sun rises and sets on it.  If you cannot discern your shared objects then I would argue you don't have a grasp on your program.

> No personal offense intended...

None taken, same sentiment here...

-DavidM

On Sat, 16 Jul 2005 22:31:08 -0400, Ben Hinkle <ben.hinkle@gmail.com> wrote:
>>> but if foo does not obey COW it will document it
>>
>> How?
>
> in it's documentation :-) The stuff that says what foo actually does. I
> think it's unusual to call a function without knowing what it does :-P

Meaningless to the 2nd, 3rd or Xth programmer reading the code. If they can read the code, look at the function and immediately *know* without reading documentation that it does/doesn't modify a parameter then this is an advantage and will always be an advantage regardless of what is said in the documentation.

>>> so that you can dup even with foo(char[] param). For example the
>>> std.stream.Stream.readLine(char[] buffer) takes a regular char[] input
>>> and
>>> documents that it will fill the buffer without dup'ing. That is, it
>>> explicitly tells the user it does not use COW.
>>
>> I dislike this and view it as wrong. The function declaration IMO should
>> be "std.stream.Stream.readLine(inout char[] buffer)"
>
> My complaint(s) with marking buffer as inout are:
> 1) it means the following code is illegal
>   char[80] buf;
>   char[] res = stdin.readLine(buf);
> it errors since buf is a static array and 'inout char[]' requires an lvalue dynamic array

True.

> 2) it mistakenly gives the impression that in the code
>   char[] buf = new char[80];
>   char[] res = stdin.readLine(buf);
> if the buffer wasn't big enough it would be resizes and the variable buf
> would be modified (not the array contents - the actual variable 'buf').

True.

Given the 2 points above it appears we require the ability to specify the following:

1. immutable array, immutable data (default IMO)
2. immutable array, mutable data (example above)
3. mutable array, mutable data (inout)

and possibly even:

4. mutable array, immutable data

a static array naturally falls into category 2 as shown above.

> In fact what readLine does (and I argue should do no matter what happens with const/etc) is it returns the actual array ptr and length and leaves the
> input buffer variable refering to the original buffer.

Thus allowing it to work with category 2 arrays, sure.

>>> ps - yes, Andrew, I know that if the author of foo forgot to mention the
>>> fact that it didn't obey COW that it would step on param so you don't
>>> have to post :-)
>>
>> Mistakes, those things we are trying to reduce, wouldn't it be nice if the
>> compiler helped a little here?
>> Some sort of enforcement of readonly for "in" would reduce errors at
>> little or no cost as far as I can see.
>
> No-one is saying it wouldn't be nice. The question is what, if anything,
> would balance all the pluses and minuses.

IMO:

1. Ability to describe the categories above.
2. Enforcement of immmutability.
3. Sensible default (category 1).

>>>> Further the data referenced by the 'data' array can be modified in this
>>>> function:
>>>>   foo(char[] param);
>>>>
>>>> It is not 'readonly' only the array is, right?
>>>
>>> Can you give a more concrete example?
>>
>> void foo(char[] param) { param[0] = 'a'; }
>>
>>> If foo changes "data" then it should document that.
>>
>> Definately, the *compiler* should point out this error.
>
> that's what some people say and, by the way, what dlint generates a warning
> for (at least it does for me - I don't think I've updated the zip file on my
> web site yet since I haven't rebuilt in Linux lately)

IMO. It's not a warning, it's an error.

>> An ideal like COW is good, having no support in holding to that ideal is
>> not good. IMO. To be clear I am not questioning the ideal, I *like* this
>> ideal. The problem is not the ideal itself it's the support we have for
>> that ideal.
>
> Yeah - sure it would be nice but it isn't a no-brainer. The arguments have been made back and forth so many times I won't even bother. I really think this horse is good and dead.

The horse isn't dead till it's been replaced by a solution.

Regan

On Sat, 16 Jul 2005 22:57:38 -0400, David Medlock <noone@nowhere.com> wrote:
> Carlos wrote:
>
>   I simply don't get how you (Ben, Walter, many others ...)
>> can be pleased with that "gentleman's agreement" esprit of COW that is currently
>> called for "save" D programming. Experience shows that it doesn't work in the
>> real world, and as much as I hate C++, I'd say that even the C++ const "solution" offers much more than your COWBGA (COW by gentleman's
>> agreement).
>>
>
> And, I simply don't understand why this is such an issue.
>
> Immutables are:
>
> A. Worthless as an optimization. Optimization is context dependent.

True.

> B. Not a memory management tool, which is what auto_ptr is typically used for.  D has memory management, its not needed.

Partially true. D does have memory management, so we wouldn't be using it to manage memory. However we could use it to manage ownership and thus COW.

> C. Defeatable in any case(without explicit hardware support) unless you remove all pointers from the language.

True. Pointers can and will probably always defeat it, however IMO that is irrelevant. If you use pointers, you pay for the power they give, simple as that. If you don't use pointers..

> So it basically just comes down to a lint-like check on parameters and a new set of type modifiers to keep track of when coding.  If there is something else what is it?

A contract. From one programmer to another of intent and implementation.

> You can currently make immutable objects. You can currently make immutable collections.

But you cannot make/have immutable arrays (arguably the default collection in D)

> But wait lets make the language twice as complex to implement so you don't have to!  C# doesnt have it, but business won't adopt it until D does!!

In C# can you return an immutable referece to internal private data, either complete or partial (a slice)?
eg.

class Foo {
  char[] private_data;
  char[] get_data() { return private_data; }
}

> This probably sounds a bit strong, but you guys talk about const like the sun rises and sets on it.

I've never even used it.

> If you cannot discern your shared objects then I would argue you don't have a grasp on your program.

All I see this as, is:
 - a means to make discerning shared objects easier
 - some additional support when programming with shared objects
 - a means of conveying intent/design to others

Regan

"David Medlock" <noone@nowhere.com> wrote in message news:dbcheo$2ljb$1@digitaldaemon.com...
> Carlos wrote:
>
>  I simply don't get how you (Ben, Walter, many others ...)
>> can be pleased with that "gentleman's agreement" esprit of COW that is
>> currently
>> called for "save" D programming. Experience shows that it doesn't work in
>> the
>> real world, and as much as I hate C++, I'd say that even the C++ const
>> "solution" offers much more than your COWBGA (COW by gentleman's
>> agreement).
>>
>
> And, I simply don't understand why this is such an issue.
>
> Immutables are:
>
> A. Worthless as an optimization. Optimization is context dependent.
> B. Not a memory management tool, which is what auto_ptr is typically used
> for.  D has memory management, its not needed.
> C. Defeatable in any case(without explicit hardware support) unless you
> remove all pointers from the language.

100% agree.

Personally I am not proposing immutability of any sort as it is abstract non-reacheable dream of humanity.

I am proposing two simple types:
read-only array/slice type and read-only pointer.

>
> So it basically just comes down to a lint-like check on parameters and a new set of type modifiers to keep track of when coding.  If there is something else what is it?
>
> You can currently make immutable objects. You can currently make immutable collections. But wait lets make the language twice as complex to implement so you don't have to!  C# doesnt have it, but business won't adopt it until D does!!

100% agree.

One comment though:
Necessary condition of business adoptation today is
robust String solution in language.
D does not provide such solution in principle now.

read-only arrays can solve this problem:
String (value) is in fact read-only array of chars.

Read-only array is just a type as any other.

>
> Given the other features of D, it is snake oil.  It looks good held up to the light, but does very little when applied.
>
> This probably sounds a bit strong, but you guys talk about const like the sun rises and sets on it.  If you cannot discern your shared objects then I would argue you don't have a grasp on your program.

We came here from different worlds with different experiences.
For some of us it looks weird that in such in principle good language
which has builtin STL comparable features you are not able
to create and pass readonly arrays but is able to define
readonly class or struct. Feeling of incompleteness of
language design.

In my personal case it was even practical problem -
I've wasted three days trying to find where one
particular array was changed.
I didn't remember problem of such magnitude in all my
C++ projects.

>
> > No personal offense intended...
>
> None taken, same sentiment here...
>

The same.

"Carlos" <Carlos_member@pathlink.com> wrote in message news:dbcd8k$2ih2$1@digitaldaemon.com...
> In article <dbca7d$2gas$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>>> and:
>>>>
>>>>     foo(data.dup);
>>>
>>> Not certain, foo might be:
>>>   foo(inout char[] param);
>>>
>>> right? you can't tell at this stage.
>>
>>Don't dup here since foo will dup if it needs to. You are probably
>>assuming
>>that foo will change param but if foo does not obey COW it will document
>>it
>>so that you can dup even with foo(char[] param). For example the
>>std.stream.Stream.readLine(char[] buffer) takes a regular char[] input and
>>documents that it will fill the buffer without dup'ing. That is, it
>>explicitly tells the user it does not use COW.
>>ps - yes, Andrew, I know that if the author of foo forgot to mention the
>>fact that it didn't obey COW that it would step on param so you don't have
>>to post :-)
>>
>>> Further the data referenced by the 'data' array can be modified in this
>>> function:
>>>   foo(char[] param);
>>>
>>> It is not 'readonly' only the array is, right?
>>
>>Can you give a more concrete example? If foo changes "data" then it should
>>document that. COW doesn't apply to functions that explicitly say they
>>don't
>>obey COW (not surprisingly). If a function doesn't say it disobeys COW
>>then
>>D programmers are free to assume it obeys COW - that's "the D way".
>>
>
> Forgive me that drastic formulation, but COW "the D way" (documentation
> only,
> no concept of ownership, auto_ptr ...) simply stinks. It's unsafe, why the
> heck not stick with C programming if that's all that D proponents have to
> say about this vital question? Don't get me wrong: D _is_ definitely a
> very
> exciting language! I simply don't get how you (Ben, Walter, many others
> ...)
> can be pleased with that "gentleman's agreement" esprit of COW that is
> currently
> called for "save" D programming. Experience shows that it doesn't work in
> the
> real world, and as much as I hate C++, I'd say that even the C++
> const "solution" offers much more than your COWBGA (COW by gentleman's
> agreement).
>
> No personal offense intended, just upset ...
>
> Peace,
> Carlos
>

Thanks, Carlos,

I am also the one who don't understand programming
based on "gentleman's agreement" principles.

Specification should start then from definition of
who is the gentleman and all needed lyrics about.

Thanks Regan,

you've taken the words out of my mouth (means I just wanted to
say the same :).

Peace,
Carlos


In article <opst1fzxu423k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Sat, 16 Jul 2005 22:57:38 -0400, David Medlock <noone@nowhere.com> wrote:
>> Carlos wrote:
>>
>>   I simply don't get how you (Ben, Walter, many others ...)
>>> can be pleased with that "gentleman's agreement" esprit of COW that is
>>> currently
>>> called for "save" D programming. Experience shows that it doesn't work
>>> in the
>>> real world, and as much as I hate C++, I'd say that even the C++ const
>>> "solution" offers much more than your COWBGA (COW by gentleman's
>>> agreement).
>>>
>>
>> And, I simply don't understand why this is such an issue.
>>
>> Immutables are:
>>
>> A. Worthless as an optimization. Optimization is context dependent.
>
>True.
>
>> B. Not a memory management tool, which is what auto_ptr is typically used for.  D has memory management, its not needed.
>
>Partially true. D does have memory management, so we wouldn't be using it to manage memory. However we could use it to manage ownership and thus COW.
>
>> C. Defeatable in any case(without explicit hardware support) unless you remove all pointers from the language.
>
>True. Pointers can and will probably always defeat it, however IMO that is irrelevant. If you use pointers, you pay for the power they give, simple as that. If you don't use pointers..
>
>> So it basically just comes down to a lint-like check on parameters and a new set of type modifiers to keep track of when coding.  If there is something else what is it?
>
>A contract. From one programmer to another of intent and implementation.
>
>> You can currently make immutable objects. You can currently make immutable collections.
>
>But you cannot make/have immutable arrays (arguably the default collection in D)
>
>> But wait lets make the language twice as complex to implement so you don't have to!  C# doesnt have it, but business won't adopt it until D does!!
>
>In C# can you return an immutable referece to internal private data,
>either complete or partial (a slice)?
>eg.
>
>class Foo {
>   char[] private_data;
>   char[] get_data() { return private_data; }
>}
>
>> This probably sounds a bit strong, but you guys talk about const like the sun rises and sets on it.
>
>I've never even used it.
>
>> If you cannot discern your shared objects then I would argue you don't have a grasp on your program.
>
>All I see this as, is:
>  - a means to make discerning shared objects easier
>  - some additional support when programming with shared objects
>  - a means of conveying intent/design to others
>
>Regan

Another comment:

> Experience shows that it doesn't work in the
> real world, and as much as I hate C++, I'd say that even the C++
> const "solution" offers much more than your COWBGA (COW by gentleman's
> agreement).

I wouldn't be so quick to accept claims about industry experience or existing experience and apply them to D. I'm not aware of any other language that has GC and COW. Trying to practice COW in a non-GC world like C/C++ is hard to do so the barrier is too high. One can practice COW in a GC language like Java but it isn't done widely. So naturally if one is writing a library in Java and trying to decide upon COW or defensive-duping one will chose defensive-duping since most people won't expect COW. In D since everyone should expect COW it would be strange to *not* use COW.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbe3f9$p88$1@digitaldaemon.com...
> Another comment:
>
>> Experience shows that it doesn't work in the
>> real world, and as much as I hate C++, I'd say that even the C++
>> const "solution" offers much more than your COWBGA (COW by gentleman's
>> agreement).
>
> I wouldn't be so quick to accept claims about industry experience or existing experience and apply them to D. I'm not aware of any other language that has GC and COW.

Sorry, I does not understand this statement.
GC is builtin in D runtime - so "D has..."  is applicable here.
Does D have builtin COW?

> Trying to practice COW in a non-GC world like C/C++ is hard to do so the barrier is too high. One can practice COW in a GC language like Java but it isn't done widely. So naturally if one is writing a library in Java and trying to decide upon COW or defensive-duping one will chose defensive-duping since most people won't expect COW. In D since everyone should expect COW it would be strange to *not* use COW.

Java authors were realists. (.NET also apply)  Probably this is the reason?
As Java systems proven to work in projects of various scales then
I believe this realistic assumption makes some sense. No?

COW is a universal technique and used everywhere when
it makes sense. Java (as D) allows only to do this manually
this is why it is used in Java but not so widespread.

C++ allows to automate COW algorithms - this is
why COW can be used naturally in C++
(e.g. http://doc.trolltech.com/3.3/shclass.html#3)

More:

1. The COW design pattern is quite orthogonal to the problem of read-only arrays and pointers.

char[#] toUpper( char[#] str )
{
   // 1) can be implemented using COW or not,
   // 2) will not modify str.
}

2. COW is expensive in terms of effectiveness
and size of final code:

char[] toUpper( char[] str )
{
   bool changed;
   for(...)
   {
       if( need to write ) // these if's are not
         if( changed )     // desirable in the cycle body
           //do new copy allocation
         else
          // proceed
   }
}

3. In real cases and classes COW leads to non-trivial
implementations - many consequences here:
- demand of more skilled programmers.
- maintainance, code reviews costs, etc.


Andrew.