www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const sucks

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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.
Oct 16 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 P.S. Guy Steele mentions Unicode operators favorably too. Nyuk-nyuk.


That's not surprising, because I think he has designed most of Fortress, that's
unicode-based.

Bye,
bearophile
Oct 16 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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.


It sure looks like they're going down the same path we did about a year ago.
Oct 16 2008
prev sibling next sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
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.


Anders mentioned "... be clearer about where the mutation occurs and where 
the side-effects are, by in a sense switching the default to be more 
functional".

Should D3 be the version that introduces default immutable storage and 
default pure functions?

IIRC, this was discussed for D2 early on in the const discussion, but the 
consensus then was that it was too big of a leap for an imperative language.
Oct 17 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Dave wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 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.


 
 Anders mentioned "... be clearer about where the mutation occurs and 
 where the side-effects are, by in a sense switching the default to be 
 more functional".
 
 Should D3 be the version that introduces default immutable storage and 
 default pure functions?
 
 IIRC, this was discussed for D2 early on in the const discussion, but 
 the consensus then was that it was too big of a leap for an imperative 
 language.


I'm very glad someone finally answered about the main thrust of the 
interview. I was a tad let down by the thundering silence following my 
post, which I attributed to its rather strident tone; in my defense, I 
have to say I was in a state of euphoria caused by such a comprehensive 
confirmation of beliefs and thinking patterns I held dear for years.

That aside, I do highly recommend interested people to watch the video. 
It is slow and boring at times, but some very interesting points are 
being made, particularly about the relationship between manycores and 
immutability (fortunately, that's also towards the beginning of the 
interview). It sure makes D look like it placed a winning bet two 
(three?) years ago when we started working on immutability.

To answer your point, Dave, I think the alea has been jacta with regard 
to D's flavor. We'll be unable to retire mutability as a matter of 
course, otherwise we might as well call the new language E :o). What we 
can do is to simplify introduction of places and regions where 
immutability is either a must, or the default. Also, we can better 
separate the places where mutability is harmless (stack data) from 
places where mutability causes problems (shared data). Walter is in fact 
working on language changes in that general direction.


Andrei
Oct 17 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 18, 2008 at 2:22 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Dave wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 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.


 Anders mentioned "... be clearer about where the mutation occurs and where
 the side-effects are, by in a sense switching the default to be more
 functional".

 Should D3 be the version that introduces default immutable storage and
 default pure functions?

 IIRC, this was discussed for D2 early on in the const discussion, but the
 consensus then was that it was too big of a leap for an imperative language.


 I'm very glad someone finally answered about the main thrust of the
 interview. I was a tad let down by the thundering silence following my post,
 which I attributed to its rather strident tone; in my defense, I have to say
 I was in a state of euphoria caused by such a comprehensive confirmation of
 beliefs and thinking patterns I held dear for years.

 That aside, I do highly recommend interested people to watch the video. It
 is slow and boring at times, but some very interesting points are being
 made, particularly about the relationship between manycores and immutability
 (fortunately, that's also towards the beginning of the interview). It sure
 makes D look like it placed a winning bet two (three?) years ago when we
 started working on immutability.


I watched it yesterday.  It was pretty interesting, but also kinda
boring in the sense that it was like watching a video version of the D
Programming Language newsgroup from a year ago.  Thanks for the link.
I didn't really have anything to say other than agree with what you
posted, so I didn't post.  :-)

Probably the most fun for me was seeing what Anders and Guy are like,
since I've heard their names many times, but never their faces or
their speaking.

--bb
Oct 17 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 18 Oct 2008 00:22:18 -0500, Andrei Alexandrescu wrote:


 Dave wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 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.


 Anders mentioned "... be clearer about where the mutation occurs and
 where the side-effects are, by in a sense switching the default to be
 more functional".
 
 Should D3 be the version that introduces default immutable storage and
 default pure functions?
 
 IIRC, this was discussed for D2 early on in the const discussion, but
 the consensus then was that it was too big of a leap for an imperative
 language.


 
 I'm very glad someone finally answered about the main thrust of the
 interview. I was a tad let down by the thundering silence following my
 post, which I attributed to its rather strident tone; in my defense, I
 have to say I was in a state of euphoria caused by such a comprehensive
 confirmation of beliefs and thinking patterns I held dear for years.
 
 That aside, I do highly recommend interested people to watch the video.
 It is slow and boring at times, but some very interesting points are
 being made, particularly about the relationship between manycores and
 immutability (fortunately, that's also towards the beginning of the
 interview). It sure makes D look like it placed a winning bet two
 (three?) years ago when we started working on immutability.
 
 To answer your point, Dave, I think the alea has been jacta with regard
 to D's flavor. We'll be unable to retire mutability as a matter of
 course, otherwise we might as well call the new language E :o). What we
 can do is to simplify introduction of places and regions where
 immutability is either a must, or the default. Also, we can better
 separate the places where mutability is harmless (stack data) from
 places where mutability causes problems (shared data). Walter is in fact
 working on language changes in that general direction.
 
 
 Andrei


I am with Bill, I didn't have much to comment on so saying, "Go D!" would 
be too much like digg, "up voted for awesomeness." I say take the silence 
as lack of disagreement.

With respect to "default immutable" I like the direction D is taking, 
where you are able to know only a small piece of the "const" and continue 
to program in a better C++. I think being able to "hide" the feature will 
be good in expanding its popularity and seems that it is being done in a 
way that is still easy to use.

And the mutable stack, great idea.
Oct 18 2008
prev sibling parent reply "Dave" <Dave_member pathlink.com> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:gdbrq5$272j$1 digitalmars.com...

 Dave wrote:

 "Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message
 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.


 Anders mentioned "... be clearer about where the mutation occurs and 
 where the side-effects are, by in a sense switching the default to be 
 more functional".

 Should D3 be the version that introduces default immutable storage and 
 default pure functions?

 IIRC, this was discussed for D2 early on in the const discussion, but the 
 consensus then was that it was too big of a leap for an imperative 
 language.


 I'm very glad someone finally answered about the main thrust of the 
 interview. I was a tad let down by the thundering silence following my 
 post, which I attributed to its rather strident tone; in my defense, I 
 have to say I was in a state of euphoria caused by such a comprehensive 
 confirmation of beliefs and thinking patterns I held dear for years.


It is great to have these D2 design initiatives reaffirmed!


 That aside, I do highly recommend interested people to watch the video. It 
 is slow and boring at times, but some very interesting points are being 
 made, particularly about the relationship between manycores and 
 immutability (fortunately, that's also towards the beginning of the 
 interview). It sure makes D look like it placed a winning bet two (three?) 
 years ago when we started working on immutability.

 To answer your point, Dave, I think the alea has been jacta with regard to 
 D's flavor. We'll be unable to retire mutability as a matter of course, 
 otherwise we might as well call the new language E :o). What we


I'd like to read more opinions on D3 "default immutapurity"... IIRC, even 
though it was considered a stretch for D2 it was actually discussed for a 
time, and (again IIRC) I don't think Walter was neccessarily the one who put 
the kabosh on that direction of thought.

If D3 doesn't try it first, someone might get "E" right in the meantime <g>. 
Anders seemed to intimate that "E" is a direction he's considering, and 
hasn't MS Research already been experimenting with something like this (not 

posted a link a while back...

Anyway, it kind of seems a logical progression to me, especially considering 
this from: http://www.digitalmars.com/d/2.0/const-faq.html#const

"Here's the biggie. Points 1..3 are insignificant in comparison. The future 
of programming will be multicore, multithreaded. Languages that make it easy 
to program them will supplant languages that don't. Transitive const is key 
to bringing D into this paradigm. The surge in use of Haskell and Erlang is 
evidence of this coming trend (the killer feature of those languages is they 
make it easy to do multiprogramming). C++ cannot be retrofitted to 
supporting multiprogramming in a manner that makes it accessible. D isn't 
there yet, but it will be, and transitive const will be absolutely 
fundamental to making it work."

Point is, what does D3 have to lose by at least exploring "default 
immutapurity" initially? Even if does turn out to be somewhat of a rabbit 
hole, it would probably either validate or serve to help improve the 
compiler and language design w.r.t. immutable storage and pure functions. 
And maybe along the way a lot of interesting things would be learned about 
porting the std. lib. perhaps?

Based on the video and where things are headed, a language that takes the 
best of imperative pragramatism and functional computer science might be 
just what we all need <g>


 can do is to simplify introduction of places and regions where 
 immutability is either a must, or the default. Also, we can better 
 separate the places where mutability is harmless (stack data) from places 
 where mutability causes problems (shared data). Walter is in fact working 
 on language changes in that general direction.


That's terrific to hear; perhaps if the changes make it into D2, and it 
turns out that developers find themselves making the majority of code 
"immutapure" anyhow, it may make sense to approach things from the other 
side for D3...


 Andrei
Oct 18 2008
parent reply John Reimer <terminal.node gmail.com> writes:
Hello Dave,


 I'd like to read more opinions on D3 "default immutapurity"... IIRC,
 even though it was considered a stretch for D2 it was actually
 discussed for a time, and (again IIRC) I don't think Walter was
 neccessarily the one who put the kabosh on that direction of thought.
 
 If D3 doesn't try it first, someone might get "E" right in the
 meantime <g>. Anders seemed to intimate that "E" is a direction he's
 considering, and hasn't MS Research already been experimenting with

 imperative language)? Someone posted a link a while back...
 
 Anyway, it kind of seems a logical progression to me, especially
 considering this from:
 http://www.digitalmars.com/d/2.0/const-faq.html#const
 



I have extremely limited experience with const, so my opinion bears very 
little weight on the matter... but, for what's its worth, I agree with Dave. 
 I think it would great to explore "immutability by default" regardless of 
the precedent set by original D and C++ (Hah! Throw caution to the wind!). 
 "Explore" being the key word: "after trying it for a bit, we might get used 
to it." :-D

I was just reading the link above too, and I notice that this would fix
consistancy 
with "Why aren't function parameters const by default?"  I imagine that's 
already been brought up multiple times before, though.

Any chance that we might see an experimental version of this?  I'm surprised 
it hasn't been tried with D considering all the other attempts made with 
const already. 

Are there any other drawbacks with default immutability other than breaking 
with the norm?

-JJR
Oct 18 2008
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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).


Andrei
Oct 18 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
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
Oct 18 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 18 2008
next sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
Oct 18 2008
next sibling parent John Reimer <terminal.node gmail.com> writes:
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
Oct 18 2008
prev sibling parent Benji Smith <dlanguage benjismith.net> writes:
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
Oct 18 2008
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
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
Oct 19 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
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
Oct 19 2008
parent Don <nospam nospam.com.au> writes:
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
Oct 20 2008
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 19 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
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
Oct 20 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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
Oct 20 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Oct 21 2008
parent Sean Kelly <sean invisibleduck.org> writes:
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
Oct 21 2008
prev sibling next sibling parent "Bent Rasmussen" <IncredibleShrinkingSphere Gmail.com> writes:
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.
Oct 18 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Oct 21 2008