Andrei Alexandrescu:
> Not all shared data is immutable. Data marked as "shared" is shared. The cool thing is that D switches the default to the "right" default.
> 
> The style of programming in which you create a new thread that joyously sees and can modify *all* of the memory space available to every other thread will go the way of the dinosaur. It's just not tenable anymore, and I predict today's mainstream programming languages abiding to that model are facing major troubles in the near future.

I agree.

Also, take a look at Clojure, one of the very few languages designed to manage multi-core CPUs. In Clojure you can use mutable data and data structures, but the default is immutable data. They argue that's the "right" default if you want to program for multi-core CPUs. If this and the Clojure experiment turn out as true/right, D2/D3 may have to change more :-)

In the close future D std lib may enjoy to grow several immutable data structures (finger trees, etc), even if the D2 language & community on the whole has not embraced the immutability much yet. Such data structures and other features in the std lib can't hurt. We'll surely talk more about this topic.

Bye,
bearophile

Jarrett Billingsley wrote:
> On Mon, Mar 2, 2009 at 12:25 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>> The style of programming in which you create a new thread that joyously sees
>> and can modify *all* of the memory space available to every other thread
>> will go the way of the dinosaur. It's just not tenable anymore, and I
>> predict today's mainstream programming languages abiding to that model are
>> facing major troubles in the near future.
> 
> Eheh, sounds like the dawn of protected memory 20 years ago ;)

Absolutely. The industry has cycles and a lot of its history rhymes. Things like multitasking, client-server computing, flat memory addressing, virtual memory, machine virtualization... they've all come and went a couple of times over decades.

As for my bet, I'm pretty confident in it. The default-isolated model is gaining traction in newer languages, in older languages that are seeing a new youth with the advent of manycores, and even in applications. Google Chrome figured that it must use OS-provided memory isolation for its tabs.

D is positioned very well, probably uniquely, to take advantage of a default-isolated model within a largely mutative language, and that is in no small part due to const and immutable. Other languages are struggling, see http://tinyurl.com/4apat7. I'm very glad that the tide on this group has effectively reversed with regard to the general opinion about const and immutable.


Andrei

bearophile wrote:
> Andrei Alexandrescu:
>> Not all shared data is immutable. Data marked as "shared" is
>> shared. The cool thing is that D switches the default to the
>> "right" default.
>> 
>> The style of programming in which you create a new thread that
>> joyously sees and can modify *all* of the memory space available to
>> every other thread will go the way of the dinosaur. It's just not
>> tenable anymore, and I predict today's mainstream programming
>> languages abiding to that model are facing major troubles in the
>> near future.
> 
> I agree.
> 
> Also, take a look at Clojure, one of the very few languages designed
> to manage multi-core CPUs. In Clojure you can use mutable data and
> data structures, but the default is immutable data. They argue that's
> the "right" default if you want to program for multi-core CPUs. If
> this and the Clojure experiment turn out as true/right, D2/D3 may
> have to change more :-)

Or Clojure. (I'm not even kidding. D has a very compelling computation model that beats the pants off traditional functional approaches.)

The thing is, in a few short years "if you want to program for multi-core CPUs" will sound as funny as "if you want to program for CPUs with more than 16-bit addressing" sounds today. Yet it was a valid qualification to add in the past, when 32- and 64-bit systems were a rarity.

> In the close future D std lib may enjoy to grow several immutable
> data structures (finger trees, etc), even if the D2 language &
> community on the whole has not embraced the immutability much yet.
> Such data structures and other features in the std lib can't hurt.
> We'll surely talk more about this topic.

Looking forward to your contributions to Phobos. Just drop pass-by-delegate like a bad habit. :o)


Andrei

hasen wrote:
> I haven't been following D for over a year .. now I notice there's a const!!
> 
> [...]

It seems the argument is centered around making "pure functions" possible.

But, surely there's a better way of doing this than borrowing const from C++.

Just like import is a better approach than #include and `namespace`

Yesterday I noticed this page http://www.digitalmars.com/d/2.0/const-faq.html
which I haven't seen before posting the topic yesterday.

Argument #2 reads: "It makes for interfaces that can be relied upon, which becomes increasingly important the more people that are involved with the code. In other words, it scales very well."

I think this is not worth the complexity, but then again, Argument#4 renders #2 as insiginificant, so I won't bother too much arguing against #2.

#4 reads: "The future of programming will be multicore, multithreaded. Languages that make it easy to program them will supplant languages that don't."

So, this is driven by the need to popularize D as a very good tool for multicore applications!

"Transitive const is key to bringing D into this paradigm."

Really? have you considered other possibilities?

How about, adding a new attribute to functions: `pure`

pure real sin( real x ) { ... }

and design the rest around this concept.

The compiler must make sure that this function is really pure:
- native types must be passed by value, not by reference
- doesn't accept pointers
- <insert some condition for objects and arrays>

If these requirements aren't met, the compiler will spit some error message "in function <F>: doing <X> voilates the `pure` attribute"

objects and arrays will need some special treatment or requirements in order to be passed to pure functions.
What are those requirements? I have given it a very deep thought yet(*), but I'm sure this approach is better than `const`.

Also, make `string` a builtin type that's immutable (like python), and discourage the use of char[] as a type for strings, (unless used to implement a special string class).

The need for a special string type also stems from the fact that char[a..b] slices bytes, not characters!


(*) A quick idea might be:
- For arrays, any statement of the type `a[b] = c` will be illegal inside a pure function. and pure functions can only call pure functions.
- For objects, any statement of the form `a.b = c` is illegal, and there must be a way to know if a method call will change the object or not. (It would be best if the compiler could detect this automatically if it's possible).
- Another approach, is to prohibit passing objects all together, and introduce some new construct that's immutable (such as a tuple, again, like python).

`pure` will probably have the same viral effects as `const`, in that any function called from a pure function must also be pure, and this viral nature will propagate to classes/objects as well.

However, the advantage is not complicating the type system more than is needed.

Also, what's the deal with const pointers?? Why should `pure` function be able to use pointers at all? Is there any real-life use case where a pure function needs to access memory instead of some abstract concept like a variable/array/tuple?


If you think about it, CTFE (compile time function execution) are `pure` already, and they're detected automatically by the compiler, with no need for explicitly marking them as such.

hasen:
> Really? have you considered other possibilities?
> How about, adding a new attribute to functions: `pure`

D2 already implements of plans to implement both transitive immutability, pure functions and to make by default data not accessible between threads :-)
See pure here:
http://www.digitalmars.com/d/2.0/function.html
(And in the future it will probably adopt even more immutability-related idioms and data structures).

Bye,
bearophile

On Mon, Mar 2, 2009 at 1:32 PM, hasen <hasan.aljudy@gmail.com> wrote:

> How about, adding a new attribute to functions: `pure`
>
> pure real sin( real x ) { ... }
>
> and design the rest around this concept.
>
> The compiler must make sure that this function is really pure:
> - native types must be passed by value, not by reference
> - doesn't accept pointers
> - <insert some condition for objects and arrays>
>
> If these requirements aren't met, the compiler will spit some error message "in function <F>: doing <X> voilates the `pure` attribute"

Umm.. maybe you didn't read far enough, but D2 already has pure functions. http://www.digitalmars.com/d/2.0/function.html

> Also, make `string` a builtin type that's immutable (like python), and
> discourage the use of char[] as a type for strings, (unless used to
> implement a special string class).
>
> The need for a special string type also stems from the fact that char[a..b] slices bytes, not characters!

Again, 'string' is defined as an alias to invariant(char)[].  It's an immutable builtin type.  It still has the problem of slicing/indexing on bytes rather than characters, but the alias is already there, Phobos already uses it extensively, and if it were changed to a struct in the future it would probably cause few to no problems.

Andrei Alexandrescu wrote:
> D is positioned very well, probably uniquely, to take advantage of a default-isolated model within a largely mutative language, and that is in no small part due to const and immutable. Other languages are struggling, see http://tinyurl.com/4apat7. I'm very glad that the tide on this group has effectively reversed with regard to the general opinion about const and immutable.
> 
> 
> Andrei


I'm not convinced, I'm just withholding judgment until there's a stable 2.0 implemented with an open-source compiler.

I suspect I'm not the only one here who thinks that way :)

Reply to hasen,

> "Transitive const is key to bringing D into this paradigm."
> 
> Really? have you considered other possibilities?
> 
> How about, adding a new attribute to functions: `pure`
> 
> pure real sin( real x ) { ... }
> 
> and design the rest around this concept.

A lot of the current const system IS designed around plans to add pure functions. You can almost read immutable as "valid as an arg for a pure function call."

> 
> The compiler must make sure that this function is really pure:
> - native types must be passed by value, not by reference
> - doesn't accept pointers
> - <insert some condition for objects and arrays>
> If these requirements aren't met, the compiler will spit some error
> message "in function <F>: doing <X> voilates the `pure` attribute"
> 

Um... that would be even more restrictive than const. Outside pointers const is more or less irrelevant with regards to function arguments so you might as well have said "pure functions can't take anything that is const or CAN be const"

> objects and arrays will need some special treatment or requirements in
> order to be passed to pure functions.

Const is a lot of very smart peoples best effort to do that special treatment.


> (*) A quick idea might be:
> - For arrays, any statement of the type `a[b] = c` will be illegal
> inside a pure function. and pure functions can only call pure
> functions.

pure int fn()
{
   int[5] foo;
   foo[0] = 5;  /// why ban this
   return foo[0];
}

> However, the advantage is not complicating the type system more than
> is needed.
> 
> Also, what's the deal with const pointers?? Why should `pure` function
> be able to use pointers at all? Is there any real-life use case where
> a pure function needs to access memory instead of some abstract
> concept like a variable/array/tuple?

Say I have several pre computed multi-MB tables that need to be used by a function. The tables never change. The function is still pure but I really can't pass the table on the stack. The same thing to a lesser degree happens with any reference type that is much larger than a pointer.

grauzone wrote:
> Does this approach fit D at all? D is a C based system programming language. Does it work to demand from everyone to obey the const rules? Couldn't all this be done manually, instead of bothering the programmer with a complex type system?

Doing it manually is how it's done in C. And the results are it is a massive failure. It's just impractical to write reliable, portable, inspectable, and maintainable multithreaded code in C. Even the experts can't get the trivial cases right, as there was a famous recent example in Dr. Dobb's (forgot the name of the article at the moment).

hasen wrote:

> hasen wrote:
>> I haven't been following D for over a year .. now I notice there's a const!!
>> 
>> [...]
> 
> It seems the argument is centered around making "pure functions" possible.
> 
> But, surely there's a better way of doing this than borrowing const from C++.

Reading the docs you must have noticed the difference between C++ const and D. In D, const and immutable are transitive, in C++ they are not. D has immutable, C++ does not. These two are the most important concepts and make the D design that much different, you can't seriously claim it is borrowed from C++.

Const in C++ is (merely) a compiler aided documentation tool, whereas const+immutable in D are the basis of a functional programming niche inside D.