On Mon, Oct 20, 2008 at 6:14 AM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 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.

Although I'm 90% sure Derek just mean that he's never seen anyone complain about it on the Euphoria mailing list, it's not a bad suggestion to collect some harder data.   Derek, if you didn't already do this the last time const by default came up, how about taking a survey on the Euphoria mailing list?  Ask if anyone finds (or found at first) the immutable parameters to be confusing.

--bb

Bill Baxter wrote:
> 
> 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.

Pure functions already work this way, so perhaps this isn't a big deal.


Sean

Sean Kelly wrote:
> Bill Baxter wrote:
>>
>> 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.
> 
> Pure functions already work this way, so perhaps this isn't a big deal.
> 
> 
> Sean

Are you sure of that? Reading the latest about pure: http://dobbscodetalk.com/index.php?option=com_content&task=view&id=745&Itemid=
I don't see were you can infer that.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Andrei Alexandrescu wrote:
> 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.

Hum, nice talk overall. I also point as interesting the part about language adoption, where the ecosystem and killer app where mentioned as important factors (although Guy's definition of killer app was a bit different than what I expected).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Bill Baxter wrote:
>>>
>>> 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.
>>
>> Pure functions already work this way, so perhaps this isn't a big deal.
> 
> Are you sure of that? Reading the latest about pure: http://dobbscodetalk.com/index.php?option=com_content&task=view&id=745&Itemid= 
> 
> I don't see were you can infer that.

I simply meant that pure functions require reference parameters to be const, not that they are implicitly const.


Sean