[haXe] Reasons const is still needed?

[Shelby Moore]

My replies to Nicolas are below my long-winded reply to Andrea.  Thank you
for sharing your thoughts.

"Andrea Griffini" wrote:
> The const concept in C++ is not meant to help the compiler but the
> programmer...

Is const useful for compiler optimization?  Maybe that would only be true
in a multi-threaded/multi-core environment (knowing we may keep in
registers because can't be written to in memory)?  Probably not relevant
when compiling to VM's bytecode, unless the VM also has a const type.  I
think NekoVM has (or will soon have) multi-threaded/multi-core
capabilities?

> ...yet I do not remember after several hundred thousands
> lines of C++ code written just a single case (not even just ONE case)
> in which the error triggered by the compiler about const-ness
> violation helped me because it was a genuine logic error...

I also have large C++ project experience (read my idea about cause of C++
spagetti later in this), and I mostly concur.  However, did you never do
any of these by accident?

if( const_var = 0 )

const_var = 0 ?...

function( array_var[i] ) where function takes a class (e.g. Array) by
reference not by value, then modifies the instance

> ...It opens a whole new class of logical problems as const-ness
> doesn't scale well (see for example how const-ness and iterators mix
> in the standard C++ library... with const_iterator and the like). They
> also got to the point of making things even harder by forbidding
> calling non-const methods on temporary objects (while there are many
> cases in which that could be useful)...

> ...Const-correctness adds rigidity to the
> written code (while the type inferencing is the opposite)...

I am having the idea that this complexity/rigidity/brittleness "type
forking creep" applies generally to subtyping all kinds.

Yet const is optional, and libraries should offer both versions.

So the creep is optional (up to what balance the programmer finds most
effective to his task), the ying&yang balance/granularity between dynamic
and static typing, as is I understand the philosophy of haXe (?):

http://lambda-the-ultimate.org/node/1625#comment-20009
http://lambda-the-ultimate.org/node/1368#comment-15638


> Please don't make programming harder if there's no proven real gain.
> In the beginning I bought this idea that it could have been nice to
> forbid people calling wrong methods but in reality experience shown me
> that the promised help is about errors that are not common (if we
> remove the errors that are related to just the const-correctness
> machinery itself) and on the other side the added cost (in logic and
> lines of code) that this machinery requires is high.

I was just reading a blog with many insightful relevant comments:

http://esr.ibiblio.org/?p=532

Agreed for small enough programs (and I share your enthusiam about the
breathe of fresh air going from C++ to dynamically typed languages), but
as diversity of integration rises, then along the outer perimeter of what
one small group/programmer(s) controls intimately, then then the static
typing afaics will become more critical.

A (my) vision for the Web3.0 is one of massively parallel collaboration
and integration at programming level, i.e. Remoting not just to the server
but between P2P clients (imho the server must die and become
distributed...this is a deep topic...).  It is a bigger vision than my own
personal coding efficiency on my own personal (smaller economy-of-scale)
projects that I entirely control:

http://ncannasse.fr/blog/captcha?lang=en#comments  (find my comment)

OFF TOPIC (because current link to what I wrote is in a private forum):

http://en.wikipedia.org/wiki/Homesteading_the_Noosphere
http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-2.html

I think open source contribution is not motivated solely by status in the
community, but more deeply it is the fact that individually each
contributor does not have the resources/time alone to produce a product
which is significant enough to gain traction in the market. Instead, by
contributing to a group effort, then there is sufficient economy-of-scale
for the sum of the individual contributions to succeed in the market.

The "gift" aspect is because the contributor is compensated indirectly,
and a direct payment for contributions would so constrict the
possibilities, that such open source projects would never spawn
(spontaneously). The contributor is not really giving away the
contribution for free, because the contributor gets to use the sum of the
effort of all the contributors, as well the contributor gains advantages
in knowledge, early adopter insight, and influence over a larger
economy-of-scale economic force. Since the contribution was worth near
ZERO alone, then sharing it, makes the contribution worth more than ZERO.
So I really disagree that the motivation is the so called "gift economy"
model of altruism and socialism.


"Nicolas Cannasse" wrote:
> ..."inline" means that the expression will be copied. So it means that
> everytime you access your Array, you will have a copy of it...

> ...In next haXe release, I will focus on reducing expressions after
> inlining. So for instance if "x" is a constant, it will reduce
> [1,2,3][1] to simply 2.

Nice. Optimizations are going to become very valuable, as installed base
grows.

That won't help with iterating over a large array, thus we shouldn't
inline them as way to make them "const".  I know you agree.  Just stating
the obvious.


>> 2. Afaics, there is no way to initialize an Array (Hash, List, etc) and
>> make it read only.
>
> You're right, this is not possible in haXe. Please note that the notion
> of "const" differs between languages "const" in your case seems to refer
> to the content. For instance in AS3 const is only the value, not its
> content.

Your point is:

const Array<T> makes the structure of the array const
Array<const T> makes the content of the array const
const Array<const T> does both

Agreed.


> For all the reasons Andrea answer lists, I'm not a supporter of the
> C/C++ const qualifier either.

Above I have raised a few exceptions to Andrea's logic.  I concur with
Andrea's experience with C++, but I want to remind that const is not
forced on the programmer.  It can be forced by poorly implemented
libraries, which do not provide non-const versions.

Perhaps one of the reasons that C++ libraries got into such a spagetti, is
because of the automatic conversions between const and non-const, and then
the ambiquity between two versions (const and non-const) of the same
overloaded method.  Since haXe does not support multiple (by arity and
return type) method or operator overloading, then I think this spagetti
can not occur.  FWIW, in my estimation and experience, what rendered C++
so brittle was the multiple arity+return type versions overloading power. 
Do NOT go there, and you will be safe.  Then again, I am not a languages
expert.

I think the most important consideration is to not add new semantics which
can open pathways to ****FORCED**** brittleness.  We must not make a
blanket misassociation of cause and effect, for example in the case of
const ant C++, it was not const causing the ****FORCED**** brittleness,
but rather the cascade due to the overzealous overloading mechanism.


>
>> 3. 'private' properties never enforce their read/write only restriction
>> (because only public access enforces the null restriction).  At least
>> the
>> compiler should generate a warning about the useless construct.
>
> Yes, that's right.


Perhaps you mean you agree at least a warning/error needs to be added, but
let me be overly verbose to make sure any nuances of my logic were not
lurking.

May I suggest at least you add a compiler error or warning when 'private'
is used with 'null' getter and/or setter.  The 'null' syntax construct is
useless semantically in context of 'private', so should not be used by the
programmer.  I got lost on that until I realized to build a test case and
then realized that the syntax was not doing the consistent semantics I
expected, then I went back and read the docs for Properties more carefully
to discover the special case semantics for 'private' Properties with
'null' setters and/or getters.  For programmers coming from C++ background
(or from PHP/JS from C++ from ANSI C from K&R C from 8086/68000 ASM from
Fortran/Pascal from Atari 800 Basic as I am), imho a compiler
error/warning would be an intuitive means of discovery.

If you want to go further, consistent (thus intuitive) semantics I think
are a desireable trait for an intuitive language.  Implementing the
expected semantics (for 'private' with 'null') would not impinge on the
programmers choices-- rather it increases freedom and programmers can
simply choose to use, or not use to use restricted private properties
(where now they only have no choice, they can't use them, even though the
syntax exists for 'public' case).


>> 4. Runtime properties setter could enforce const behavior at runtime,
>> but
>> this is unacceptable (for performance and regression reasons).
>
> Yes, any runtime check if out of question right now.

Well I meant (maybe you did also?) that the programmer can right now
define setters and getters to enforce a restriction on non-use at runtime.
 But I think we agree that is not really a solution to any thing.  When
one uses Dynamic typing, one inherently gives up compile time safety.  So
making something const in runtime is sort of meaningless.


>> Seems to me that why go to all the trouble of having this wonderful
>> compile time type checking, and not be able to protect againt errant
>> writes in large memory structures?
>
> You can still do that, by building your structure with either read-only
> public fields or getter-only methods.


Yeah I thought of that too, e.g.:

Array<MyReadOnlyUInt>

However, then it means I can NOT do this:

var a : Array<MyReadOnlyUInt> = [1, 2, 3, 4, ...

And then my application (currently Discrete Cosine Transform for JPEG)
slows down, because each access is not:

a[i]

Rather becomes:

a[i].property()  (even if I abstract it with a getter)

If I declare the MyReadOnlyUInt.property() inline, then will haXe compiler
optimize back to a[i] in byte code?

And can the compiler be made smart enough to check whether
MyReadOnlyUInt.new() takes an Int, so I can continue to use literal array
constructor?


> Of course, any subclass of it will be able to modify the data,

Yes I guess the subclass could override the property.  I could only
protect against this by either never accepting a subclass of
MyReadOnlyUInt as input and/or declaring MyReadOnlyUInt final (no
subclassing allowed).  Or you could enable 'private' with 'null' setter
semantics.


> but
> that's not a problem IMHO since I'm not in favor of the principles of
> "defending programmers against themselves" that some restrictive
> language design adopts.

Hey I love also the productivity of the complete freedom over my code.  Do
not get me wrong.  haXe will always have this freedom, due to the Dynamic,
Untyped, and cast, as long some hole is opened to ****FORCED****
brittleness as I explained above.

At the library public interfaces, do we need to think more broadly in a
network and interoperability, where we are not defending against ourselves
or our small intimate group, but against the diversity and creep of
complexity of interoperated use of our published class?

Because of the Dungar Number, there is limit to our ability to scale our
control over not being hurt by others:

http://en.wikipedia.org/wiki/Dunbar_number

We have to then set some limits on how much we can do dynamically (without
restrictions), whether it be the # of friends, the # of emails we can read
per day, or the types of interoperability our code was designed to handle.
 We won't be able to simply get out there and inform every consumer
(programmer) of our class, "Hey don't do that".  I think the lack of the
warning as I explained in item #3 above is a good example of this concept.

HaXe may just yet accomplish what Java was claiming, "write once, run
every where", but maybe not in the way we were visualizing at the time. 
My vision of how we get there is not yet complete, and I continue to
experiment and learn.

Best also,

Me:
http://www.linkedin.com/in/shelbyhmooreiii