On Sat, 16 Jul 2005 18:31:08 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> On Fri, 15 Jul 2005 15:47:42 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opsty7jlu423k2f5@nrage.netwin.co.nz...
>>>>> Compiler will check function for immutable violations.
>>>>
>>>> It is easy to say, try to describe such "check".
>>>
>>> I have done so several times, with several different ideas.
>>>
>>>>>> One unknown programmer to other unknown programmer?
>>>>>
>>>>> The programmer of the function will guarantee it, the compiler will
>>>>> enfore
>>>>> it.
>>>>
>>>> How?
>>>>
>>>> class Recordset
>>>> {
>>>>     Field[] fields() { ... } // supposed to be readonly
>>>
>>> Then you need to label it as such. Either 'readonly', 'const', etc.
>>>
>>>>     Value[] values() { ... } // may be readonly, may be not
>>>
>>> Not possible, make up your mind.
>>>
>>>> }
>>>>
>>>> static Field f;
>>>>
>>>> bool Foo( in Recordset rs )
>>>> {
>>>>     rs.fields[0].foo();
>>>>     rs.values[0].bar();
>>>>     f = rs.fields[0];
>>>> }
>>>>
>>>> Given Foo example above try to describe
>>>> what needs to be done by compiler to
>>>> verify immutability of rs parameter.
>>>
>>> The same way C++ const does it.
>>
>> I lost you here....
>> Are you proposing to mark all immutable methods and references by
>> const/readonly
>> as in C++?
>
> Yes. Have you _read_ any of the proposals I've made?

Before you suggest this is the "clutter" Walter & Co have referred to, it's not the same as C++ const as more sensible defaults can be chosen (because we're in beta stage of development), eg:

in parameters: immutable
return values: mutable
local variables: mutable

So where code does not deviate from the above no keyword/clutter is required.

So far none of my proposals have attempted to address class members which do/don't mutate. As you've said this is mostly covered with private, protected, etc and get/set methods (assuming immutable arrays and pointers are implemented)

"One mans clutter is another mans design contract"

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opstztp6iy23k2f5@nrage.netwin.co.nz...
> On Fri, 15 Jul 2005 15:47:42 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsty7jlu423k2f5@nrage.netwin.co.nz...
>>>>> Compiler will check function for immutable violations.
>>>>
>>>> It is easy to say, try to describe such "check".
>>>
>>> I have done so several times, with several different ideas.
>>>
>>>>>> One unknown programmer to other unknown programmer?
>>>>>
>>>>> The programmer of the function will guarantee it, the compiler will
>>>>> enfore
>>>>> it.
>>>>
>>>> How?
>>>>
>>>> class Recordset
>>>> {
>>>>     Field[] fields() { ... } // supposed to be readonly
>>>
>>> Then you need to label it as such. Either 'readonly', 'const', etc.
>>>
>>>>     Value[] values() { ... } // may be readonly, may be not
>>>
>>> Not possible, make up your mind.
>>>
>>>> }
>>>>
>>>> static Field f;
>>>>
>>>> bool Foo( in Recordset rs )
>>>> {
>>>>     rs.fields[0].foo();
>>>>     rs.values[0].bar();
>>>>     f = rs.fields[0];
>>>> }
>>>>
>>>> Given Foo example above try to describe
>>>> what needs to be done by compiler to
>>>> verify immutability of rs parameter.
>>>
>>> The same way C++ const does it.
>>
>> I lost you here....
>> Are you proposing to mark all immutable methods and references by
>> const/readonly
>> as in C++?
>
> Yes. Have you _read_ any of the proposals I've made?

Yes I did.
I am reading everything related to const/readonly/immutable .

So, am I right interpretting you this way:

Proposal is to add the same system of const/mutable tags which
C++ has now - const/mutable tags for variables and class methods.
Main difference is that we will make explicit 'in typename varname'
modifier behave as ' in const typename varname'.

Am I correct?

On Fri, 15 Jul 2005 23:54:29 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opstztp6iy23k2f5@nrage.netwin.co.nz...
>> On Fri, 15 Jul 2005 15:47:42 -0700, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>> news:opsty7jlu423k2f5@nrage.netwin.co.nz...
>>>>>> Compiler will check function for immutable violations.
>>>>>
>>>>> It is easy to say, try to describe such "check".
>>>>
>>>> I have done so several times, with several different ideas.
>>>>
>>>>>>> One unknown programmer to other unknown programmer?
>>>>>>
>>>>>> The programmer of the function will guarantee it, the compiler will
>>>>>> enfore
>>>>>> it.
>>>>>
>>>>> How?
>>>>>
>>>>> class Recordset
>>>>> {
>>>>>     Field[] fields() { ... } // supposed to be readonly
>>>>
>>>> Then you need to label it as such. Either 'readonly', 'const', etc.
>>>>
>>>>>     Value[] values() { ... } // may be readonly, may be not
>>>>
>>>> Not possible, make up your mind.
>>>>
>>>>> }
>>>>>
>>>>> static Field f;
>>>>>
>>>>> bool Foo( in Recordset rs )
>>>>> {
>>>>>     rs.fields[0].foo();
>>>>>     rs.values[0].bar();
>>>>>     f = rs.fields[0];
>>>>> }
>>>>>
>>>>> Given Foo example above try to describe
>>>>> what needs to be done by compiler to
>>>>> verify immutability of rs parameter.
>>>>
>>>> The same way C++ const does it.
>>>
>>> I lost you here....
>>> Are you proposing to mark all immutable methods and references by
>>> const/readonly
>>> as in C++?
>>
>> Yes. Have you _read_ any of the proposals I've made?
>
> Yes I did.
> I am reading everything related to const/readonly/immutable .
>
> So, am I right interpretting you this way:
>
> Proposal is to add the same system of const/mutable tags which
> C++ has now

No. I would use different defaults, specifically 'in' parameters.

> - const/mutable tags for variables

Yes, but note local variables default to being mutable, in parameters to immutable, return values to mutable. So in the common cases no tag is required.

> and class methods.

Not methods themselves, just return values. Access protection private, protected, etc handles the rest.. or so you keep saying.

> Main difference is that we will make explicit 'in typename varname'
> modifier behave as ' in const typename varname'.

No. Implicit 'in' should be readonly IMO.

Regan

On Friday July 15th, 2005 21:11:11 -0700, Andrew Fedoniouk gave us this perl ...

> I would like to return to basics again.

All I want is the compiler to warn me when it detects that some code will change something that I've said that I don't want changed.

If I get that warning, then I can decide how to handle it. Maybe COW, or maybe something else...whatever!

Can I have a compiler that is actively trying to help me find my mistakes?

-- 
Anonymous Bosch
--
The view will be the same no matter which path you take to the mountain top.

Andrew Fedoniouk wrote:
> "Walter" <newshound@digitalmars.com> wrote in message news:dba6ee$vtj$1@digitaldaemon.com...
> 
>>"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message
>>news:db7e7e$143d$1@digitaldaemon.com...
>>
>>>Consider this:
>>>// somwhere in class RecordsetView ....
>>>
>>>Field[] fields = myrecordset.fields;
>>>
>>>// and in galaxy far, far away....
>>>
>>>fields.sort; // pretty harmless, isn't it?
>>
>>The example code violates the basic COW principle of "Do not modify the
>>referenced data unless you KNOW you are the sole reference to it."
>>
>>
> 
> 
> The problem is that WE (team of developers)
> DON'T KNOW in ALMOST ALL CASES is this variable
> is a sole owner of array or no.
> Is this particular array which arrived through three or four function calls
> modifiable or not? Just no time to trace what and where.
> Practically all this will end up with "always dup before passing"
> approach in design guidelines. Especially dealing with third party
> libraries.
> 
> Walter, I understand your position. You are lucky to
> write compilers alone. You have a luxury to know each
> variable origins. But for projects in 500000 lines of code
> and 40 developers this COWboy's deal is not working.
> Trust me.
> 
> People in industry will not vote for D because of
> it is extremely hard to assemble team of 40
> developers all following COW rules.
> 
> Andrew.
> 
> 
Sorry I don't buy this.

Companies adopt technology because of:
1. Support and longevity. Sun and MS will fix their software and they arent closing their doors anytime soon.
2. Availability of pools of programmers if they are needed. (this is the hard one for new languages)
3. Availability of tools.
4. Interoperability with their existing systems.

#1 is always number one, but the others could be swapped depending on the company.  Middle management decision makers might listen to developer talk about feature B, but in the end those reasons end up deciding.

There is absolutely nothing stopping you from making immutable Objects or Collections.  Walter has given you all the tools to do so.  He has also given you low level powerful tools to do other tasks.

As a language spec it has all the capability of C#, and C# is taking off(for the reasons above).

-DavidM

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dbaa5l$130t$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:dba6ee$vtj$1@digitaldaemon.com...
>>
>> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:db7e7e$143d$1@digitaldaemon.com...
>>> Consider this:
>>> // somwhere in class RecordsetView ....
>>>
>>> Field[] fields = myrecordset.fields;
>>>
>>> // and in galaxy far, far away....
>>>
>>> fields.sort; // pretty harmless, isn't it?
>>
>> The example code violates the basic COW principle of "Do not modify the referenced data unless you KNOW you are the sole reference to it."
>>
>
> The problem is that WE (team of developers)
> DON'T KNOW in ALMOST ALL CASES is this variable
> is a sole owner of array or no.
> Is this particular array which arrived through three or four function
> calls
> modifiable or not? Just no time to trace what and where.
> Practically all this will end up with "always dup before passing"
> approach in design guidelines. Especially dealing with third party
> libraries.

I don't know what you mean by "dup before passing". It should be "dup before writing". Passing data around is trivial. I agree if one doesn't take the time to know if something can be written to it should be duped but that is exactly what COW is about. To me the biggest problem of COW in D is "premature duping": the extra copies made by people trying to be prematurely defensive that wind up wasting GC resources. Like premature optimization, duping without writing is putting effort at the wrong location.

> Walter, I understand your position. You are lucky to
> write compilers alone. You have a luxury to know each
> variable origins. But for projects in 500000 lines of code
> and 40 developers this COWboy's deal is not working.
> Trust me.

Why? Java and Fortran seem to have large programs written in them. And Java doesn't even have COW. At least Fortran has the convention that you don't write to overlapping inputs.

> People in industry will not vote for D because of
> it is extremely hard to assemble team of 40
> developers all following COW rules.

It would be easy to assemble 40 C++ programmers to follow a slightly
different COW: Const Or Walk. :-P
To me the biggest things holding back D is the lack of tools, docs and
libraries - the language is fine.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dbaa5l$130t$1@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message news:dba6ee$vtj$1@digitaldaemon.com...
> > The example code violates the basic COW principle of "Do not modify the referenced data unless you KNOW you are the sole reference to it."
> The problem is that WE (team of developers)
> DON'T KNOW in ALMOST ALL CASES is this variable
> is a sole owner of array or no.

The corollary to the stated principle is "If you don't KNOW that you are the sole owner of the referenced data, then dup it before modifying it."

> Is this particular array which arrived through three or four function
calls
> modifiable or not? Just no time to trace what and where. Practically all this will end up with "always dup before passing" approach in design guidelines. Especially dealing with third party libraries.

No, "always dup before passing" is approaching the problem from the wrong direction, and is not COW. COW is "dup when you modify it". Never dup because someone ELSE might modify it. Dup when you DO modify it and you DON'T KNOW if you are the sole owner.


> Walter, I understand your position. You are lucky to
> write compilers alone. You have a luxury to know each
> variable origins. But for projects in 500000 lines of code
> and 40 developers this COWboy's deal is not working.
> Trust me.
>
> People in industry will not vote for D because of
> it is extremely hard to assemble team of 40
> developers all following COW rules.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dbavgb$1jrn$1@digitaldaemon.com...
> I don't know what you mean by "dup before passing". It should be "dup
before
> writing". Passing data around is trivial. I agree if one doesn't take the time to know if something can be written to it should be duped but that is exactly what COW is about. To me the biggest problem of COW in D is "premature duping": the extra copies made by people trying to be
prematurely
> defensive that wind up wasting GC resources. Like premature optimization, duping without writing is putting effort at the wrong location.

Right.

If there is a .dup in the code that is not obviously followed by writing to the data, then odds are pretty strong the code is not COW. For example,

    return data.dup;

and:

    foo(data.dup);

are almost certainly wrong (unless data is stack allocated).

"AJG" <AJG_member@pathlink.com> wrote in message news:dba86h$11nc$1@digitaldaemon.com...
> In article <dba7gh$117s$1@digitaldaemon.com>, Walter says...
> >"AJG" <AJG_member@pathlink.com> wrote in message news:dba3e0$oqq$1@digitaldaemon.com...
> >> PS: What about the idea about making all parameters by reference. Would
> >this
> >> allow for optimization with compile-time verification of immutability?
> >Would
> >> this make _anything_ easier?
> >
> >It'll make things inefficient on modern CPU's, because of cache misses
when
> >the indirection is done.
>
> Can I assume this happens regardless of whether it's a reference or a
pointer?

References are just syntactic sugar for pointers, so yes.

> So then what's the "sweet spot" in this tradeoff? Where does it become
more
> efficient to pass by reference rather than by value?

That can only be determined on a case by case basis using careful profiling. Results also vary depending on which CPU model you're using.

> Can whole structs be cached?

Yes.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opstzt8tg823k2f5@nrage.netwin.co.nz...
> The suggestion was not to make 'all' parameters pass by reference but rather to allow the compiler to choose the most efficient in any given situation. This would only be used in situations where you don't care how it's passed, so long as it's efficient.
>
> Specifically suggested were 'in' parameters. Unlike 'out' or 'inout' passing by reference is not specified/required. (in fact it's not required for them either, but would be inefficient if implemented with copies).
>
> This would allow us to pass large structs without resorting to using pointers.
>
> There is a requirement then that an 'in' parameter passed by reference is not be mutable. Some sort of readonly enforcement would need to be used to ensure this.

Ok, I understand. And you're right.