On Sun, Oct 19, 2008 at 6:35 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> John Reimer wrote:
>>
>> Are there any other drawbacks with default immutability other than breaking with the norm?
>
> Well for one thing much of OO style involves creating few objects that hold
> their state and evolve in well-defined ways. Many objects are
> "entity" objects, meaning that holding a reference to a particular object is
> the way to stay in touch. In FP style new objects are being created all the
> time, so the programming styles are very different.
>
> But by and large I find it very interesting that the tide has changed to the extent that this option is being discussed. It's good progress from the const-should-die-a-gruesome-death view :o).

I think you mean "this option is being discussed *once again*".  It was discussed quite a lot before the current invariant/const was implemented.  The consensus was definitely that it was worth a shot. But it did not get a shot.

I recall Walter's main argument against it was that local variable really shouldn't be const-by-default since you're usually creating them because you want to manipulate them.  But then you end up with a system where local variable declarations and parameter declarations follow very different rules.  "int[] foo" in one place means something different from "int[] foo" in the other place.  I'm not convinced this would be that confusing, though.  There could be other problems with const-by-default in parameters, but that one doesn't seem like such a big deal.

--bb

Looks familiar :-)

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=77477

- Bent


"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> skrev i meddelelsen news:gd85n2$9rq$1@digitalmars.com...
> Just got this from Eric Niebler:
>
> http://tinyurl.com/4apat7
>
> Guess what Anders Heljsberg and Guy Steele have to say about future of programming languages.
>
> Immutable and eliminating side effects are necessary. Quickly written down from Anders: "...we need support for immutable data at the language level..." "...so that the compiler can infer that there is isolation..." "... formalization of immutability... we don't have them in the language and it's nontrivial to put them in... and that's the big challenge." He goes on and describes the difficulties... and mentions "pure functions" and "transitivity" and "functional extensions"!!! "Pure FP is not the solution... what we try to do is to have islands of purity in functional style and switch between default to functional in a hybrid style of programming... the answer is not at the extreme..."
>
> This is huge. You have to listen to it to hear just how huge it is. He is essentially describing some of the difficulties we have encountered and already solved in D2, so it looks we have a strategic advantage.
>
> This is the confirmation I hoped was going to come someday. If it surprises me, it that it comes so early, so unequivocally, and so aligned terminologically. I'm in Nirvana.
>
>
> Andrei
>
> P.S. Guy Steele mentions Unicode operators favorably too. Nyuk-nyuk. 

Bill Baxter wrote:
> I think you mean "this option is being discussed *once again*".  It
> was discussed quite a lot before the current invariant/const was
> implemented.  The consensus was definitely that it was worth a shot.
> But it did not get a shot.

Yes, it was discussed a lot.

> I recall Walter's main argument against it was that local variable
> really shouldn't be const-by-default since you're usually creating
> them because you want to manipulate them.  But then you end up with a
> system where local variable declarations and parameter declarations
> follow very different rules.  "int[] foo" in one place means something
> different from "int[] foo" in the other place.  I'm not convinced this
> would be that confusing, though.  There could be other problems with
> const-by-default in parameters, but that one doesn't seem like such a
> big deal.

The problem is things like:

  void foo(int[] a)
  {
    int[] b;
  }

so a is const, and b is mutable? That's very confusing. It gives the appearance of D having a lot of wacky and arbitrary semantic rules.

Hello Walter,

> Bill Baxter wrote:
> 
>> I think you mean "this option is being discussed *once again*".  It
>> was discussed quite a lot before the current invariant/const was
>> implemented.  The consensus was definitely that it was worth a shot.
>> But it did not get a shot.
>> 
> Yes, it was discussed a lot.
> 
>> I recall Walter's main argument against it was that local variable
>> really shouldn't be const-by-default since you're usually creating
>> them because you want to manipulate them.  But then you end up with a
>> system where local variable declarations and parameter declarations
>> follow very different rules.  "int[] foo" in one place means
>> something different from "int[] foo" in the other place.  I'm not
>> convinced this would be that confusing, though.  There could be other
>> problems with const-by-default in parameters, but that one doesn't
>> seem like such a big deal.
>> 
> The problem is things like:
> 
> void foo(int[] a)
> {
> int[] b;
> }
> so a is const, and b is mutable? That's very confusing. It gives the
> appearance of D having a lot of wacky and arbitrary semantic rules.
> 


I'll have to go dig up all the past discussions on this (there were volumes that I mostly skipped over).

My impression of mutable by default was more than function parameters.

Weren't we talking something like this when referring to "immutable by default":

// void foo(int[] a)
// {
//     int b;
//     mutable int c;
//
//     /* block declaration */
//
//     mutable //     {
//          int d;
//          int e;
//      }
// }

'a' is an implied const (immutable) parameter.
'b' is const by default
'c', 'd', and 'e' are all declared mutable.

Isn't this what is meant by "constant by default"?  I haven't described class variables here, of course.

I'm nervous to comment further lest I have totally misunderstood what's going on. :)

-JJR

Hello John,

> My impression of mutable by default was more than function parameters.
> 
> Weren't we talking something like this when referring to "immutable by
> default":
> 
> // void foo(int[] a)
> // {
> //     int b;
> //     mutable int c;
> //
> //     /* block declaration */
> //
> //     mutable
> //     {
> //          int d;
> //          int e;
> //      }
> // }
> 'a' is an implied const (immutable) parameter.
> 'b' is const by default
> 'c', 'd', and 'e' are all declared mutable.
> Isn't this what is meant by "constant by default"?  I haven't
> described class variables here, of course.
> 
> I'm nervous to comment further lest I have totally misunderstood
> what's going on. :)
> 
> -JJR
> 


Sorry, I really should have reviewed this before posting.  I see that const-by-default was referring to parameters only.  Shame on me.

Even so, I think the argument that it would make D confusing if parameters are const and variables are mutable by default merely falls to convention: it mostly disruptive because it's such a big change from C++. Perhaps that's a big argument against it, but ultimately it's usefulness might be more important? I can't say much for or against, I suppose, so I'll avoid saying much more until I understand this better.  I suppose the other matter discussed was concerning class objects as Andrei indicated, which appears to be discussed much in past threads, if I'm not mistaken.

-JJR

John Reimer wrote:
> My impression of mutable by default was more than function parameters.
> 
> Weren't we talking something like this when referring to "immutable by default":
> 
> // void foo(int[] a)
> // {
> //     int b;
> //     mutable int c;
> //
> //     /* block declaration */
> //
> //     mutable //     {
> //          int d;
> //          int e;
> //      }
> // }
> 
> 'a' is an implied const (immutable) parameter.
> 'b' is const by default
> 'c', 'd', and 'e' are all declared mutable.
> 
> Isn't this what is meant by "constant by default"?  I haven't described class variables here, of course.
> 
> I'm nervous to comment further lest I have totally misunderstood what's going on. :)

My understanding of the proposal was that "const by default" was only for function parameters. And I agree with walter that it's a little but wonky and unexpected.

But I liked it anyhow, and I think people could have easily gotten used to the distinction in constness between function params and all other variables. Especially since the compiler would always be able to catch the mistake.

--benji

On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:

> The problem is things like:
> 
>    void foo(int[] a)
>    {
>      int[] b;
>    }
> 
> so a is const, and b is mutable? That's very confusing. It gives the appearance of D having a lot of wacky and arbitrary semantic rules.

I work with the Euphoria language and this has been the case since its begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird.

In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable.

Your fears may need empirical evidence before I would take them seriously.


-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On Mon, Oct 20, 2008 at 5:50 AM, Derek Parnell <derek@psych.ward> wrote:
> On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:
>
>> The problem is things like:
>>
>>    void foo(int[] a)
>>    {
>>      int[] b;
>>    }
>>
>> so a is const, and b is mutable? That's very confusing. It gives the appearance of D having a lot of wacky and arbitrary semantic rules.
>
> I work with the Euphoria language and this has been the case since its begining. No one, from newbie-coder to experienced coders of a number of languages have EVER thought this as weird.
>
> In Euphoria, there is NO WAY one can change a function's argument. The caller of a function can have complete confidence that any argument passed will not have its value changed by the function. However, variables local to the function are not immutable.
>
> Your fears may need empirical evidence before I would take them seriously.

Yeh, and on the other side, I remember way back when I was learning C as a newbie that I found it was surprising that parameters acted just like local variables.  When you think about it, yeh, they are basically, but as a newbie the thought never occurred to me that they were (or should be) the same thing.

Even now in D what you can do with them is different.  You can only have 'in' or 'ref' on parameters, not on local variables.  So I too think more evidence is needed that such a change will make code confusing.

--bb

Bill Baxter wrote:
> On Mon, Oct 20, 2008 at 5:50 AM, Derek Parnell <derek@psych.ward> wrote:
>> On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:
>>
>>> The problem is things like:
>>>
>>>    void foo(int[] a)
>>>    {
>>>      int[] b;
>>>    }
>>>
>>> so a is const, and b is mutable? That's very confusing. It gives the
>>> appearance of D having a lot of wacky and arbitrary semantic rules.
>> I work with the Euphoria language and this has been the case since its
>> begining. No one, from newbie-coder to experienced coders of a number of
>> languages have EVER thought this as weird.
>>
>> In Euphoria, there is NO WAY one can change a function's argument. The
>> caller of a function can have complete confidence that any argument passed
>> will not have its value changed by the function. However, variables local
>> to the function are not immutable.
>>
>> Your fears may need empirical evidence before I would take them seriously.
> 
> Yeh, and on the other side, I remember way back when I was learning C
> as a newbie that I found it was surprising that parameters acted just
> like local variables.  When you think about it, yeh, they are
> basically, but as a newbie the thought never occurred to me that they
> were (or should be) the same thing.

Learning C, I remember being astonished that it was legal to modify a parameter. It still feels wrong to me, so I never do it. Even in asm!
They've always felt to me that they are part of the calling function.

> Even now in D what you can do with them is different.  You can only
> have 'in' or 'ref' on parameters, not on local variables.  So I too
> think more evidence is needed that such a change will make code
> confusing.
> 
> --bb

Derek Parnell wrote:
> On Sat, 18 Oct 2008 20:36:51 -0700, Walter Bright wrote:
> 
>> The problem is things like:
>>
>>    void foo(int[] a)
>>    {
>>      int[] b;
>>    }
>>
>> so a is const, and b is mutable? That's very confusing. It gives the appearance of D having a lot of wacky and arbitrary semantic rules.
> 
> I work with the Euphoria language and this has been the case since its
> begining. No one, from newbie-coder to experienced coders of a number of
> languages have EVER thought this as weird.
> 
> In Euphoria, there is NO WAY one can change a function's argument. The
> caller of a function can have complete confidence that any argument passed
> will not have its value changed by the function. However, variables local
> to the function are not immutable.
> 
> Your fears may need empirical evidence before I would take them seriously.

Well claiming that you know what everybody using Euphoria has ever thought sets the standard pretty low in terms of evidence.

Andrei