Logical const

Fawzi Mohamed fawzi at gmx.ch
Fri Dec 3 15:09:53 PST 2010


On 3-dic-10, at 17:23, Bruno Medeiros wrote:

> On 03/12/2010 13:22, Steven Schveighoffer wrote:
>> On Fri, 03 Dec 2010 08:00:43 -0500, Bruno Medeiros
>> <brunodomedeiros+spam at com.gmail> wrote:
>>
>>> The above are not trivial differences, so I do not agree that it
>>> constitutes full logical const, only a limited form of it. More
>>> concretely, it doesn't constitute logical const in in the sense  
>>> where
>>> you can use that as argument to say "logical const already exists,
>>> it's just clunky to use", so let's add it to the language formally.
>>> Like if mutable members where just syntax sugar, or a betterment of
>>> safety rules.
>>
>> I disagree, I think it does prove logical const already exists. How  
>> do
>> you define logical const?
>>
>
> I define logical const as the ability to specify that operations on  
> a given object reference will not modify the logical state of that  
> object (through that reference), and the ability for the compiler to  
> verify that statically.

No for me the compiler *cannot* verify logical const. Logical const  
can be verified only in some occasions:
for example a place where to store the result of a suspended  
evaluation (what functional languages call a thunk).
A dataflow variable for example in general cannot be verified by the  
compiler, but should also be logically const.
Normally the user should use only suspended pure operations or  
dataflow variables, so it is safe.
Still in D I want to be able to *implement* them, and that  cannot be  
verified by the compiler.
As for why I want to be able to implement it in D, the reasons (beyond  
the fact that it is a system language) is that in some occasions one  
can implement it much more efficiently that any generic implementation  
(for example if one knows that the value cannot be x, x can be  
directly used to mark the need to update it, and if one knows the  
functions and arguments to call an explicit thunk (i.e. closure with  
heap allocation) can also be spared.

So for me it is ok that the hole to implement them is ugly (haskell  
for example has unsafePerformIO), but I want an officially sanctioned  
hole.
I am actually against using "mutable", it that solution should be  
accepeted then the name should look much worse, like unsafeValue or  
something like that.
Casual use should be discouraged.

> Logical state is defined (_not very precisely though_) as the data  
> subset of an object which is relevant for opEquals calculations. So  
> in that Matrix example the elements of the Matrix arrays are part of  
> the logical state, the cached determinant is not.

No for me logical const means that all methods applied to the object  
will always return the same value, it is not connected with the data  
stored, that is exactly the reason one wants mutable values.

> Mutable members is one way to implement support for logical const in  
> a language. (There could be other ways.)

yes

In any case I find tail const (or weak const, as I prefer to call it,  
which is simply const on referred data, but not on the one that is  
always locally stored on the stack) more important, and *that* can be  
enforced by the compiler.
I think that "in" should mean the weak const, not const.

Fawzi


More information about the Digitalmars-d mailing list