www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The motivation for const (the big picture)

reply guslay <guslay gmail.com> writes:
I would appreciate if Walter or maybe someone who assisted to the D conference
could enlight me.

Taking a step back from the syntax/expressiveness debate, I would like to
understand better where do const/invariant reside in the grand scheme of
things. Is the current const/invariant the end goal, or does it lead to
something else?

Why is const/invariant necessary?

- Is it just a checklist feature? [I think it's more than that, but C++ users
are accustomed to this, it might be an handicap not to have it]

- Is it mainly there because it's required to implement something else? [Say,
immutable string] 

- Or is it there because it is useful just by itself? In that case, why? What's
the *primary* intent?
 - To protect programmers from making mistakes?
 - For documentation?
 - As a "contract" in functions interface?
 - To enable certain optimizations?

And mainly, how does it stand with respect to pure function and functional
programming? Is it required from that or is it more of a complementary feature?

Lots of questions....
Jan 05 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
guslay wrote:


 I would appreciate if Walter or maybe someone who assisted to the D
 conference could enlight me.
 
 Taking a step back from the syntax/expressiveness debate, I would like to
 understand better where do const/invariant reside in the grand scheme of
 things. Is the current const/invariant the end goal, or does it lead to
 something else?
 
 Why is const/invariant necessary?


I don't think I match your criteria for someone you want to hear from, but
I'll try anyway ;)

I view const as part of an API specification.  Essentially a contract
promising to not modify the data that is passed into a function (or held by
a class, etc...).

Conceptually, this is useful (like in, out, ref parameters in functions)
because it helps understand the intended functionality and gives a
mechanism for the compiler to catch accidental violations of the intent.

Unfortunately, const (AKA readonly) does not do anything for the compiler
besides giving it extra work to check code.  There's no guarantee that data
won't be changed when calling functions or through actions of another
thread.  Because of this, the compiler can not optimize code under the
assumption that the data never changes.  As I understand it, this is the
purpose of invariant.  I've also heard (but never seen
justification/explanation) that invariant helps with functional
programming.

I share a lot of your questions, and I hope someone who knows more than me
can jump in and explain this stuff better.
Jan 06 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:

 I've also heard (but never seen
 justification/explanation) that invariant helps with functional
 programming.


I think it only helps in the sense that it makes automatic 
parallelization of functional-style programs possible.  If I foreach 
over some data structure and all the inputs are invariant, then the 
compiler is free to do that in any order or in parallel because it knows 
that executing a function on one element cannot possibly change the 
value of another element by any means.  With a C++ readonly style const 
you only know that you're not changing it, but there are a dozen ways 
that it could be changed out from under you in sneaky and unexpected, 
but perfectly legal, ways.

That said, I'm not sure what that's going to look like in D.  It seems 
like making use of invariant for functional programming in D will 
require a totally different programming style where you make everything 
invariant all the time.  It doesn't seem like you'll be able to just 
"toss in" a little FP to an existing project without a lot of redesign.

--bb
Jan 06 2008
parent reply Dan <murpsoft hotmail.com> writes:
Bill Baxter Wrote:

 Jason House wrote:

 I've also heard (but never seen
 justification/explanation) that invariant helps with functional
 programming.


 
 I think it only helps in the sense that it makes automatic 
 parallelization of functional-style programs possible.  If I foreach 
 over some data structure and all the inputs are invariant, then the 
 compiler is free to do that in any order or in parallel because it knows 
 that executing a function on one element cannot possibly change the 
 value of another element by any means.


[snip]

Invariant allows for alot of assumptions to be made about something; but it's
because we assume merrily that it's okay for the program to crash if something
changes out from under us even if the program is paused.

So we can:
- fearlessly run parallel functions over the same data
- cache something and expect it to be correct indefinitely
- trust our libraries, and 3rd parties not to mangle our stuff
- catch accidental writes to something we wanted read-only
- make guarantees to clients and employers (our code *cannot* change your x)
- be aware the opposite is probably true for non-invariants

In all honesty though, we must know it's a bluff.  The code *can* change out
from under you.  It just won't by your own hand.

Regards,
Dan
Jan 06 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Dan wrote:

 Bill Baxter Wrote:

 Jason House wrote:

 I've also heard (but never seen
 justification/explanation) that invariant helps with functional
 programming.


 I think it only helps in the sense that it makes automatic 
 parallelization of functional-style programs possible.  If I foreach 
 over some data structure and all the inputs are invariant, then the 
 compiler is free to do that in any order or in parallel because it knows 
 that executing a function on one element cannot possibly change the 
 value of another element by any means.


 [snip]
 
 Invariant allows for alot of assumptions to be made about something; but it's
because we assume merrily that it's okay for the program to crash if something
changes out from under us even if the program is paused.
 
 So we can:
 - fearlessly run parallel functions over the same data
 - cache something and expect it to be correct indefinitely
 - trust our libraries, and 3rd parties not to mangle our stuff
 - catch accidental writes to something we wanted read-only
 - make guarantees to clients and employers (our code *cannot* change your x)
 - be aware the opposite is probably true for non-invariants
 
 In all honesty though, we must know it's a bluff.  The code *can* change out
from under you.  It just won't by your own hand.


So you're saying the likely usage patterns will involve giving the 
compiler "hints" in the form of casts to invariant on data that actually 
isn't?

--bb
Jan 06 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Bill Baxter wrote:

 Dan wrote:

 Bill Baxter Wrote:

 Jason House wrote:

 I've also heard (but never seen
 justification/explanation) that invariant helps with functional
 programming.


 I think it only helps in the sense that it makes automatic 
 parallelization of functional-style programs possible.  If I foreach 
 over some data structure and all the inputs are invariant, then the 
 compiler is free to do that in any order or in parallel because it 
 knows that executing a function on one element cannot possibly change 
 the value of another element by any means.


 [snip]

 Invariant allows for alot of assumptions to be made about something; 
 but it's because we assume merrily that it's okay for the program to 
 crash if something changes out from under us even if the program is 
 paused.

 So we can:
 - fearlessly run parallel functions over the same data
 - cache something and expect it to be correct indefinitely
 - trust our libraries, and 3rd parties not to mangle our stuff
 - catch accidental writes to something we wanted read-only
 - make guarantees to clients and employers (our code *cannot* change 
 your x)
 - be aware the opposite is probably true for non-invariants

 In all honesty though, we must know it's a bluff.  The code *can* 
 change out from under you.  It just won't by your own hand.


 
 So you're saying the likely usage patterns will involve giving the 
 compiler "hints" in the form of casts to invariant on data that actually 
 isn't?
 
 --bb


I think he's trying to say that it's possible to cast away invariant.
Jan 07 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D conference
could enlight me.


This is clearly a frequently asked question, so I added it to the FAQ:

http://www.digitalmars.com/d/faq.html#const
Jan 06 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D 
 conference could enlight me.


 
 This is clearly a frequently asked question, so I added it to the FAQ:
 
 http://www.digitalmars.com/d/faq.html#const


Some of those FAQs need updating:
* Why doesn't D have an interface to C++ as well as C?
* Why cannot D code directly call existing C++ code?


Both should mention D2.0's C++ interfacing capabilities. (with link to 
here http://www.digitalmars.com/d/cpp_interface.html)
Jan 07 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Some of those FAQs need updating:
 * Why doesn't D have an interface to C++ as well as C?
 * Why cannot D code directly call existing C++ code?
 
 
 Both should mention D2.0's C++ interfacing capabilities. (with link to 
 here http://www.digitalmars.com/d/cpp_interface.html)


Done.
Jan 07 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Some of those FAQs need updating:
 * Why doesn't D have an interface to C++ as well as C?
 * Why cannot D code directly call existing C++ code?


 Both should mention D2.0's C++ interfacing capabilities. (with link to 
 here http://www.digitalmars.com/d/cpp_interface.html)


 
 Done.


One more thing:
"Doesn't C++ support strings, bit arrays, etc. with STL?"..."How much 
confidence can you have that this [std::string] is all working 
correctly, how do you fix it if it is not?"

The "how do you fix it?" argument applies even moreso to a built-in 
implementation of string than a library one.  So I'd strike that bit.

--bb
Jan 07 2008
prev sibling parent reply BC <notmi_emayl_adreznot hotmail.com.remove.not> writes:
On Mon, 07 Jan 2008 20:38:51 -0000, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Bill Baxter wrote:

 Some of those FAQs need updating:
 * Why doesn't D have an interface to C++ as well as C?
 * Why cannot D code directly call existing C++ code?
   Both should mention D2.0's C++ interfacing capabilities. (with link  
 to here http://www.digitalmars.com/d/cpp_interface.html)


 Done.


can I ask, which compiler combinations does interfacing work with? is it  
just
when the executable formats are the same?
Jan 08 2008
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
BC wrote:

 Bill Baxter wrote:

 Some of those FAQs need updating:
 * Why doesn't D have an interface to C++ as well as C?
 * Why cannot D code directly call existing C++ code?
   Both should mention D2.0's C++ interfacing capabilities. (with link 
 to here http://www.digitalmars.com/d/cpp_interface.html)




 
 can I ask, which compiler combinations does interfacing work with? is it 
 just
 when the executable formats are the same?


DMD on Windows is compatible with DMC.
DMD on Linux is compatible with some version of g++ (not sure which one).
GDC should be compatible with g++ from the same version.

The ones that are compatible with some version of g++ should also be 
compatible with "similar" g++ versions and IIRC the Intel C++ compiler 
on Linux (perhaps depending on version of g++ and icc).
Jan 10 2008
prev sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
Walter Bright wrote:

 guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D 
 conference could enlight me.


 
 This is clearly a frequently asked question, so I added it to the FAQ:
 
 http://www.digitalmars.com/d/faq.html#const


Small thing: "of little import" should probably read "of little importance"?

L.
Jan 07 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Lionello Lunesu wrote:

 Walter Bright wrote:

 guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D 
 conference could enlight me.


 This is clearly a frequently asked question, so I added it to the FAQ:

 http://www.digitalmars.com/d/faq.html#const


 
 Small thing: "of little import" should probably read "of little 
 importance"?


It's valid English.  The meaning is the same.

--bb
Jan 07 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter wrote:


 Lionello Lunesu wrote:

 Walter Bright wrote:

 guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D
 conference could enlight me.


 This is clearly a frequently asked question, so I added it to the FAQ:

 http://www.digitalmars.com/d/faq.html#const


 
 Small thing: "of little import" should probably read "of little
 importance"?


 
 It's valid English.  The meaning is the same.
 
 --bb


Not all native english speakers recognize that as valid english (take me for
example).  It's probably better to use the more common wording to avoid
people thinking it's poorly worded.
Jan 07 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:

 Bill Baxter wrote:
 

 Lionello Lunesu wrote:

 Walter Bright wrote:

 guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D
 conference could enlight me.


 This is clearly a frequently asked question, so I added it to the FAQ:

 http://www.digitalmars.com/d/faq.html#const


 Small thing: "of little import" should probably read "of little
 importance"?


 It's valid English.  The meaning is the same.

 --bb


 
 Not all native english speakers recognize that as valid english (take me for
 example).  It's probably better to use the more common wording to avoid
 people thinking it's poorly worded.


Yeh true.  Effective communication is all about considering your target 
audience.

--bb
Jan 07 2008
parent "Bruce Adams" <tortoise_74 yeah.who.co.uk> writes:
On Tue, 08 Jan 2008 03:51:28 -0000, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:


 Jason House wrote:

 Bill Baxter wrote:


 Lionello Lunesu wrote:

 Walter Bright wrote:

 guslay wrote:

 I would appreciate if Walter or maybe someone who assisted to the D
 conference could enlight me.


 This is clearly a frequently asked question, so I added it to the  
 FAQ:

 http://www.digitalmars.com/d/faq.html#const


 Small thing: "of little import" should probably read "of little
 importance"?


 It's valid English.  The meaning is the same.

 --bb


  Not all native english speakers recognize that as valid english (take  
 me for
 example).  It's probably better to use the more common wording to avoid
 people thinking it's poorly worded.


 Yeh true.  Effective communication is all about considering your target  
 audience.

 --bb


I'd hate to be stuck with a less rich vocabularly to suit the lowest  
common denominator.
(me no like less words to make simple)

Wikipedia has an interesting approach. There's a simplified form of  
English as a distinct language/translation

http://en.wikipedia.org/wiki/Wikipedia:Simple_English_Wikipedia
http://en.wikipedia.org/wiki/Simplified_English
Jan 07 2008
prev sibling parent Daniel Lewis <murpsoft hotmail.com> writes:
Robert Fraser Wrote:

 Dan wrote:

 So we can:
 - fearlessly run parallel functions over the same data
 - cache something and expect it to be correct indefinitely
 - trust our libraries, and 3rd parties not to mangle our stuff
 - catch accidental writes to something we wanted read-only
 - make guarantees to clients and employers (our code *cannot* change 
 your x)
 - be aware the opposite is probably true for non-invariants

 In all honesty though, we must know it's a bluff.  The code *can* 
 change out from under you.  It just won't by your own hand.






*someone else said*:

 So you're saying the likely usage patterns will involve giving the 
 compiler "hints" in the form of casts to invariant on data that actually 
 isn't?
 
 --bb


 
 I think he's trying to say that it's possible to cast away invariant.


When we program, we are making the assumption that data doesn't arbitrarily
change between steps in our algorithm "deux est machina".  If it does, most
often the algorithm will fail to perform the desired function.

What "invariant" does, is to define this assumption, and clarify which parts
we're going to decide we'll accept changing out from under us, and which parts
aren't allowed to.

The parts that aren't allowed to, are asserted by the compiler; but that by no
means makes the program's outcome certain.  Just because your own code cannot
tamper with it, doesn't mean that it can't be tampered with in a VM, by a
debugger, or whatnot; and so the assumption is known to be false for at least
some case.  Hence we declare the results "undefined" and be done with it.

This is honesty.

Now, because we declare awareness of this assumption, we are able to cause the
program to make some optimizations and restrictions which may do the things I
stated in the above list.

Hope that clarifies my view on it.
Jan 07 2008