What purpose to const besides functional programming?

[superdan]

Jason House Wrote:

> Walter Bright Wrote:
> 
> > Jason House wrote:
> > > What *other* purposes does the const system serve besides
> > > opening the door to functional programming?  I understand that the
> > > const system must remain simple to be usable.
> > 
> > 1. It makes function APIs self-documenting.
> > 2. Invariance allows one to pass large data structures around by 
> > reference yet treat them as if one passed them by value. Strings are the 
> > canonical example of that.
> > 3. Const allows one function to service both mutable and invariant 
> > arguments.
> > 4. Invariant data can be placed in hardware protected readonly memory, 
> > such as ROM.
> > 5. Invariant data does not have to be synchronized to be multithread 
> > accessible.
> > 6. Invariant data improves the ability of automated tools to make 
> > inferences about what is happening. Optimization is an example of such.
> 
> #5 is not true.  Invariant functions require synchronization because they can manipulate global state.  If #5 is restricted to direct data access without using properties or member functions, then I'd agree with it.  Of course, that qualification eliminates most of the benefit from #5. notice how walter says "data" and you say "function" and you'll pretty much have understood where the problem in your reasoning was.

of course #5 is true. looks like there was and still is a basic misunderstanding of data vs. function behavior with regard to immutability. 

don't confuse data with functions. invariant data -> can't modify it even with the sas. that means no synchronization on data necessary. invariant function -> applies to invariant object and may or may not require synchronization. but sure as shit invariant data does not need synchronization.

> #2 makes me think a bit...  When would const objects be used to manipulate non-const data that isn't effected by transitive const?  It seems to me that simple cases could work, but it quickly breaks down when trying to generalize.
> For example, I could write a log utility that writes messages to standard out.  To write to any output, I'd need to store where to write log output to.  Maybe I could circumvent the const system and create a global object that looks up where to write stuff.  That'd let me pass around my logger as an invariant object but then it'd be making an extra function call every time something gets logged.  That's a horrible design.  Advanced compiler tricks may eliminate the overhead, but it doesn't mean it'd save headache for the programmer.  

this is backwards. the logger object is not const. the shit it logs is const as the logger has no business changing it.

> > > Pure functions requires that any shared data is invariant.
> > 
> > Yes, but invariant data does not require purity.
> 
> I translate that as "I didn't implement it that way".  Also, we need to distinguish between raw access to invariant data and use of (invariant) methods.  See my discussion of your #5 above

which was wrong, and your translation doesn't make it any better.