Hi,

How about this:

Make 'explicit' in parameters readonly.
Make naked parameters copies ("shallow snapshots"). (As they are, currently).
Offer an "immutable" block statement for those that need it.

immutable (someVar, someOtherVar, ...) {
// I desperately need someVar and
// someOtherVar to be immutable here.
}

For the most part, parameters need only be readonly, not actually immutable. Immutability (for all parameters) via runtime checking is insane. I think we've established that. It is OK, however, for small blocks, if required.

So, unless someone posts some magical cheap way to fuse readonly and immutable, I think we are stuck. Time to make some compromises. The reason C++ has its const is probably because that's the only feasible way. I would, however, _like_ to be proven wrong.

Cheers,
--AJG.

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?

In article <dba1d0$mu7$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>I would like to return to basics again.
>
>I. Readonly variable.
>
>What is readonly parameter or variable?
>
>readonly (c++::const) something means that in given scope any write-over operations are disabled for such variable.
>
>*given scope* - means not only function body but also
>the whole application domain if e.g. such variable is static
>or member field of some class. Generally speaking
>such variable has type having operator= and the like
>disabled.
>
>readonly variable does not mean that variable will not be changed. Such variable is an alias of some memory location - it just means that using this particular alias it is imposible to overwrite that memory location.
>
>II. Immutable variable.
>
>What is 'immutable' or 'immutable in' then?
>Abstract meaning of immutable variable - snapshot of data under
>this variable. Immutability of function parameter is a gurantee
>that in the scope of this function any two consequent readings
>of any data location reachable from this var will lead to the same
>result.  This apply to function parameters and other variables e.g.
>member field of some class.
>
>III. 'in' parameter in current version.
>
>Currently 'in' parameter is a copy (shallow snapshot) of some value passed to the function. 'in' parameter variable is an alias of stack location. By now it is *mutable* variable.
>
>IV. readonly arrays and pointers. Implementation.
>
>My initial proposal is not about immutability. It is about
>readonly versions of two primitive reference types.
>Not more not less. Implementation of this types
>is simple, feasible and verifiable by compiler 100% of cases
>theoretically and practically. Implementation of such two
>types is pretty much mechanical process similar to modification
>of static type table.
>
>V. Implementation of 'in immutability'.
>
>Let's take a look on possible immutability implementations:
>We are considering only non-intrusive implementations here,
>i.e. impementations without readonly/const tags of variables
>and methods. As such tags are known to produce
>"clutter", (c) Walter and others.
>
>  V.1. Snapshot.
>         Snapshot as a process, also known as 'marshalling',
>         used in RPC implementations (e.g. in COM/CORBA)
>         to pass parameters across process/machine
>         boundaries. Demands synchronized access to passing
>         value and all values reachable from it.
>         Practically is not feasible to be short.
>
>  V.2. GC-like scan against passing variable.
>         Don't need too much comments here.
>         In fact V.1. is a form of GC too.
>         Copying GC this time.
>
>Here is the first question: So, how is
>this beaitiful "immutable in" supposed to
>be implemented?
>
>And here is the second question:
>Can anybody provide *realistic* example of some
>practical task where such "immutable in" is the must?
>I will greatly appreciate if this example will not
>be reasonably reproducible with readonly arrays/pointers
>and use of access attributes for other types.
>
>---------------------------
>Andrew Fedoniouk.
>http://terrainformatica.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."

"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.

Hi,

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?

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

Can whole structs be cached?

Thanks,
--AJG.

"AJG" <AJG_member@pathlink.com> wrote in message news:dba3e0$oqq$1@digitaldaemon.com...
> Hi,
>
> How about this:
>
> Make 'explicit' in parameters readonly.

In given function:
void emitXML( in XMLNode root ) { ... }
what this 'readonly' means exactly?

> Make naked parameters copies ("shallow snapshots"). (As they are, currently).

Ok. And?

> Offer an "immutable" block statement for those that need it.
>
> immutable (someVar, someOtherVar, ...) {
> // I desperately need someVar and
> // someOtherVar to be immutable here.
> }

XMLNode root;
immutable (root)
{
....
}

What it means exactly? Snapshot of the whole tree with memory region lock?

>
> For the most part, parameters need only be readonly, not actually
> immutable.
> Immutability (for all parameters) via runtime checking is insane. I think
> we've
> established that. It is OK, however, for small blocks, if required.
>
> So, unless someone posts some magical cheap way to fuse readonly and
> immutable,
> I think we are stuck. Time to make some compromises. The reason C++ has
> its
> const is probably because that's the only feasible way. I would, however,
> _like_
> to be proven wrong.

I've already published here article about possible referential immutability
implementation.
It uses the same principles as C++ const, readonly/mutable tags versus
const/mutable.
Combined with Java absence of slices and pointers plus some fixes at VM
level (runtime checks)
it makes referential (only) immutability practically feasible at compile
time.
Referential immutability,  I believe, is exactly "brute force deep
readonlyness" -
only calls of readonly methods are allowed against given variable and all
objects *potentially* accessible from it.

Theoretically it is possible to deduce value of readonly tag for any given method of the class. But this practically also needs 'mutable' keyword at least.

>
> Cheers,
> --AJG.
>
> 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?

I cannot see how "all parameters by reference" differ from current situation in D.

"compile-time verification of immutability" of any given variable is not
practically possible.
Again, if it would be possible then GC will not be needed as compiler
can build list of free blocks in compile time.
Problem of the same nature to be short.

Andrew.

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?

Regan

"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.

On Fri, 15 Jul 2005 22:54:22 -0700, Walter <newshound@digitalmars.com> wrote:
> "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.

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.

Regan

On Fri, 15 Jul 2005 23:40:52 -0700, Andrew Fedoniouk <news@terrainformatica.com> 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.

A reference counting or auto pointer implementation could be used to ensure you are the sole referance. Sadly we can't write one of them in D.

The other solution is what we're discussin some sort of readonly mechanism enforced by the compiler or (dbc/debug) runtime.

Regan

Hi,

>> Make 'explicit' in parameters readonly.
>
>In given function:
>void emitXML( in XMLNode root ) { ... }
>what this 'readonly' means exactly?

This is readonly from your own definitions (i.e. "I. Readonly").

>> Make naked parameters copies ("shallow snapshots"). (As they are, currently).
>
>Ok. And?

This is for when you want to be able to modify the parameter at the function (for convinience), but you don't want the changes to propagate to the caller.

void Foo(int A)    { A += 10; return (A); } // OK: A is a copy.
void Foo(in int B) { B += 10; return (B); }
// ERROR: A is the original, but readonly.

>> Offer an "immutable" block statement for those that need it.
>>
>> immutable (someVar, someOtherVar, ...) {
>> // I desperately need someVar and
>> // someOtherVar to be immutable here.
>> }
>
>XMLNode root;
>immutable (root)
>{
>....
>}
>
>What it means exactly? Snapshot of the whole tree with memory region lock?

It means immutability checked at runtime. There have been various proposals to implement this, all fairly expensive, if I recall correctly. One method is to serialize all vars at the beginning, and at the end, and compare if they are the same. I guess a checksum could also work. The point is, it can be slow, because it wouldn't happen a lot.

>> For the most part, parameters need only be readonly, not actually
>> immutable.
>> Immutability (for all parameters) via runtime checking is insane. I think
>> we've
>> established that. It is OK, however, for small blocks, if required.
>>
>> So, unless someone posts some magical cheap way to fuse readonly and
>> immutable,
>> I think we are stuck. Time to make some compromises. The reason C++ has
>> its
>> const is probably because that's the only feasible way. I would, however,
>> _like_
>> to be proven wrong.
>
>I've already published here article about possible referential immutability
>implementation.
>It uses the same principles as C++ const, readonly/mutable tags versus
>const/mutable.
>Combined with Java absence of slices and pointers plus some fixes at VM
>level (runtime checks)
>it makes referential (only) immutability practically feasible at compile
>time.
>Referential immutability,  I believe, is exactly "brute force deep
>readonlyness" -
>only calls of readonly methods are allowed against given variable and all
>objects *potentially* accessible from it.

Didn't Walter say this is impossible at compile time because the data could come in through an arbitrarily-complex path? Did you show him your article?


>Theoretically it is possible to deduce value of readonly tag for any given method of the class. But this practically also needs 'mutable' keyword at least.
>
>>
>> Cheers,
>> --AJG.
>>
>> 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?
>
>I cannot see how "all parameters by reference" differ from current situation in D.
>
>"compile-time verification of immutability" of any given variable is not practically possible.

How is this different than what your article suggests? Doesn't it do exactly that?

>Again, if it would be possible then GC will not be needed as compiler
>can build list of free blocks in compile time.
>Problem of the same nature to be short.
>
>Andrew.

Cheers,
--AJG.