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+s...@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
