Is all this Invarient **** er... stuff, premature optimisation?

[Me Here]

Janice Caron wrote:

>2008/4/28 Me Here <p9e883002 at sneakemail.com>:
>(I forget which module you have to import to get assumeUnique). But
>what you mustn't ever do is cast away invariant.
>
>>  1) Whatever happened to polymorphism?
>
>What's polymorphism got to do with anything? A string is an array, not a 
>class.
>
>
>>  So, if I assign the results of a string library function/method to a
>>  mutable variable (Just a variable really. An invariant variable is a
>>  constant!), then it should be possible (*IS* possible) to recognise
>>  that and return an appropriate result.
>
>Functions don't overload on return value.

They don't? Why not? Seems like a pretty obvious step to me.

Rather than having to have methods:

     futzIt_returnString()
     futzIt_returnInt()
     futzIt_returnReal()
     futzIt_returnComplex()

where 'futzIt' might me "read a string from the command line and return it 
to me as some type (if possible)",

I can just do

int i = futzIt( ... );
real r = futzIt( ... );

And let the compiler work out which futzIt() I need to call, and take care 
of mangling the names to allow them to coexists.
You mean D doesn't already have this facility?

Seems lie it would be a far more productive and useful expenditure of 
effort than all this invariant stuff.

>
>
>>  The idea that runtime obtained or derived strings can be made truly
>>  invariant is purely theoretical.
>
>But the fact that someone else might be sharing the data is not.

By "someone else" you mean 'another thread'?
If so, then if that is a possibility, if my code is using threads, then I, 
the programmer,
will be aware of that  and will be able to take appropriate choices.

I /might/ chose to use invariance to 'protect' this particular piece of 
data from the problems
of shared state concurrency--if there is any possibility that I intend to 
shared this particular piece of data.
But in truth, it is very unlikely that I *will* make /that/ choice. Here's 
why.

What does it mean to make and hold multiple (mutated) copies of a single 
entity?

That is, I obtain a piece of data from somewhere and make it invariant.
Somehow two threads obtain references to that piece of data.
If none of them attempt to change it, then it makes no difference that it 
is marked invariant.
If however, one of them is programmed to change it, then it now has a 
different,
version of that entity to the other thread. But what does that mean? Who 
has the 'right' version?

Show me a real situation where two threads can legitimately be making 
disparate modifications to a single entity,
string or otherwise, and I'll show you a programming error. Once two 
threads make disparate modifications to an entity,
they are separate entities. And they should have been given copies, not 
references to a single copy, in the first place.

If the intent is that the share a single entity, then any legitimate 
modifications to that single entity should be reflected
in the views of that single entity by both threads. And therefore 
subjected to locking, or STM or whatever mechanism is
used to control that modification.

This whole thing of invariance and concurrency seems to be aimed at 
enabling the use of COW.
Which smacks of someone trying to emulate fork-like behaviours using 
threads.

And if that is the case, and I very much hope it isn't, then let me tell 
you as someone who is intimately familiar with the
one existing system that wen this route (iThreads: look'em up), that it is 
a total disaster,

The whole purpose and advantage of multi-threading, over multi-processing, 
is (mutable) shared state. And the elimination of
costs of serialisation and narrow bandwidth if IPC in the forking 
concurrency mode. Attempting to emulate that model
using threading gives few of its advantages, all of its disadvantages, and 
throws away all of the advantages of threading.
It is a complete and utter waste of time and effort.

If the aim is to simplify the use of threading for common programming 
scenarios
and bring it within the grasp of non-threading specialist programmers,
then there are far more effective and less costly ways of achieving that.

>
>>  But one of the
>>  major attractions of D over C/C++ is its built-in string types
>
>D has no built in string type. string is just an alias for 
>invariant(char)[].

Semantics.

D has built-in support for a string-type (see 
http://www.digitalmars.com/d/2.0/overview.html) from which I quote:

     "Strings"

     "String manipulation is so common, and so clumsy in C and C++, that it needs direct support in the language".
     "Modern languages handle string concatenation, copying, etc., and so does D".
     "Strings are a direct consequence of improved array handling."

What invariant strings do, and as far as I can see the only significant 
thing they do, is to reinvent the clumsiness
of C & C++ by making strings a second-class data type again.

If the point is to try and make threading easier, it will fail miserably 
once people realise that it creates the scope for
multiple concurrent versions of supposedly single entities. Which breaks 
just about every programming rule in the book,
and creates scope for far more intractable errors than it fixes.

>That's one approach. Another is don't try to treat strings as mutable.

If the intention of invariance is some move toward OO or functional 
purity, then I again quote from the same document:

     "Who D is Not For"

     [some categories elided]

     "Language purists. D is a practical language, and each feature of it is evaluated in that light, rather than by an ideal. "
     "For example, D has constructs and semantics that virtually eliminate the need for pointers for ordinary tasks. "
     "But pointers are still there, because sometimes the rules need to be broken."
     "Similarly, casts are still there for those times when the typing system needs to be overridden."

Cheers, b.


--