Fully transitive const is not necessary

[guslay]

Janice Caron Wrote:

> On 01/04/2008, guslay <guslay at 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.