• guslay <guslay gmail.com> Apr 02 2008
• "Janice Caron" <caron800 googlemail.com> Apr 02 2008
• guslay <guslay gmail.com> Apr 02 2008
• "Steven Schveighoffer" <schveiguy yahoo.com> Apr 02 2008

guslay <guslay gmail.com> writes:

Janice Caron Wrote:

 On 01/04/2008, guslay <guslay gmail.com> wrote:
  -= A const method may exhibit side effects =-
 You may call static/global functions and modify static/global data, modify
mutable objects accessible through static/global pointers, perform I/O, etc.


 Of course. Again, you're stating the obvious.


It's a walkthrough.


  -= Const != thread-safe =-

  A method with potential side effects is not implicitly thread-safe.


 Again with the obvious. Is there any point to this? Are you somehow
 suggesting that anyone on this newsgroup believes otherwise?


Yes. Sometimes.


  -= Const is not the key to functional programming =-


 Yes it is. But const is /part/ of the solution, not the /whole/ of the
 solution.


That's what I said.


 And likewise it would be a tough job making
 functional programming work without (transitive) const.


I still assume const to be transitive. But transitivity is not absolute.


  Immutability is required for FP, but const "mathematical" guarantees are too
weak to provide that ability.


 I don't understand that sentence. Why is the word mathematical in
 quotes? I hope you're not suggesting that mathematics is a dodgy
 discipline, because it's probably the /only/ discipline in the
 universe which offers solid proofs for its theorems. Even ignoring
 that, I have no idea what you're trying to say here.


Abusive claims are made hinting take const/invariant provide a strong
mathematical foundation to support multiprogramming, without details. I am
trying to show that the const/invariant model, as applied to qualifying
functions (not data), is too weak to prove such thing Hence the quotes.

I meant no disrespect to your field.

  -= Pure function + invariant data is required for FP =-


 That sounds reasonable, though it should really say /transitive/ invariant
data.


You are right. As I've stated in the introduction, a really meant invariant
functions, not const, and I should have used that terminology.


  This concept is not yet into place, but I will define it has a method that
only call other pure functions, and performs read-only operation on its class
members and static/global data.


 INCORRECT. A pure function cannot read static or global data, period.


Let's settle for invariant/enum global data.


  -= Const is part of the interface, not part of the implementation =-
  -= Allowing mutable members does not break or weaken the const model =-


  What mutable does is allowing finer-grained control over the powerful const
system. It does not weaken it, it controls its scope. Those are orthogonal
issues (as far as I have yet to see an instance where having half the fields of
an object const, instead of all the fields of the object, limits anything in
any way).


 Really?
 
     class C
     {
         int x;
         mutable int y; // just pretend this is legal
     }
 
     void f(const(C) c)
     {
         int temp = y;
         y = temp + 1;
     }
 
 Now imagine two threads calling f simultaneously with the same c.
 Imagine a thread switch occurs between the two statements.


You have just made the mistake to assume that const implies thread-safe.


  -= Mutability is required =-


  An object is fully initialized, but some parts are lazyly evaluated and
require mutable members.


 Then it isn't const.


Based on a very restrictive definition of what const is.


  a) Mutable members are not allowed. The object cannot be passed as const. The
non-const object is passed to the external function, renouncing to any control
at all on the immutability of the object.


 There are trivial workarounds. Instead of
 
     class C
     {
         int x;
         mutable int y;
     }
 
     void f(const(C) c);
 
 just do this:
 
     class C
     {
         int x;
     }
 
     class D
     {
         int y;
     }
 
     void f(const(C) c, D d);
 
 This is just a simple matter of saying what you really mean.


I would love to be able to bend framework interfaces at my will.


  b) Mutable members are allowed. The object is passed as const. The caller can
be confident that the internal state of the object will not be modified beyond
the intention of the class designer.


 ...or it might be screwed up entirely as a result of a threading conflict.


Again, const/invariant != thread safe. Which is obvious, but often forgotten.

"Janice Caron" <caron800 googlemail.com> writes:

On 02/04/2008, guslay <guslay gmail.com> wrote:
  You have just made the mistake to assume that const implies thread-safe.


No I didn't. I stated that const is a /necessary/ condition for thread
safety, but nowhere did I claim it was a /sufficient/ condition.

I assumed (demonstrated, in fact), that mutable implies thread-unsafe,
but not that const implies thread-safe. There is a difference.

guslay <guslay gmail.com> writes:

Janice Caron Wrote:

 On 02/04/2008, guslay <guslay gmail.com> wrote:
  You have just made the mistake to assume that const implies thread-safe.


 No I didn't. I stated that const is a /necessary/ condition for thread
 safety, but nowhere did I claim it was a /sufficient/ condition.
 
 I assumed (demonstrated, in fact), that mutable implies thread-unsafe,
 but not that const implies thread-safe. There is a difference.


If const does not imply thread-safety, mutable clearly does not. No one as
claimed that. Bizarrely, I was under the impression that you made it sound like
it was my position. At least we agree on that.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Janice Caron" wrote
 On 02/04/2008, guslay wrote:
  You have just made the mistake to assume that const implies thread-safe.


 No I didn't. I stated that const is a /necessary/ condition for thread
 safety, but nowhere did I claim it was a /sufficient/ condition.

 I assumed (demonstrated, in fact), that mutable implies thread-unsafe,
 but not that const implies thread-safe. There is a difference.


Here is the full context:

  What mutable does is allowing finer-grained control over the powerful 
 const system. It does not weaken it, it controls its scope. Those are 
 orthogonal issues (as far as I have yet to see an instance where having 
 half the fields of an object const, instead of all the fields of the 
 object, limits anything in any way).


 Really?

     class C
     {
         int x;
         mutable int y; // just pretend this is legal
     }

     void f(const(C) c)
     {
         int temp = y;
         y = temp + 1;
     }

 Now imagine two threads calling f simultaneously with the same c.
 Imagine a thread switch occurs between the two statements.


guslay is saying "mutable gives you finer control over const, does not 
weaken it..."

You are saying "Really? <example that proves mutable const is not 
thread-safe>"

I think guslay interpreted your response as a rebuttal to his argument, and 
so he thought (as I did) that what you were saying is:

"Really?  Here's an example that is not thread safe (but is if mutable isn't 
allowed)"

In reality, I think your example has nothing to do with the difference 
between transitive and logical const at all.

-Steve