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

[Me Here]

Janice Caron wrote:

> 2008/4/28  <p9e883002 at sneakemail.com>:
> >  import std.string;
> > 
> >  int main( string[] args) {
> >     char[] a = cast(char[])args[0].toupper();
> 
> **** UNDEFINED BEHAVIOR ****
> (1) args might be placed in a hardware-locked read-only segment. Then
> the following line would fail
> (2) there might be other pointers to the string, which expect it never
> to change.
> 
> >     a[2..5] = "XXX";
> >     a = cast(char[])tolower( cast(string)a );
> >     writefln(a);
> >     return 0;
> >  }
> > 
> >  Finally. It works.
> 
> But not necessarily on all architectures, because of the undefined
> behavior. This is how you do it without undefined behavior.
> 
>     import std.string;
> 
>     int main( string[] args) {
>         string a = args[0].toupper();
>         a = a[0..2] ~ "XXX" ~ a[5..$];
>         a = a.tolower();
>         writefln(a);
>         return 0;
>     }

Ack! That's horrible. Instead of using the information I have, the
offset and length of the slice I want to manipulate, I have to derive
two offset/length pairs to the bits I do not want to do anything to.

1) Whatever happened to polymorphism?

Eg. Why can't the standard string library recognise that I, as the
programmer, know what I need to do to my data. It's my job.

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. Duplicating the input if
required.

The idea that runtime obtained or derived strings can be made truely
invariant is purely theoretical. Whilst the compiler can place compile
time contants into hardware protected, read-only memory segments, doing
this at runtime would be horribly costly and hardly beneficial.

IA-86 allows memory to be set readonly at runtime, but only in page
sized chunks. Which means that either:

- every derived string would need to be placed in its own 4k multiple
sized chunk of ram.

-or, each page would have to constantly be switched from read-only to
read-write and back again as new entities are added and old ones go out
of scope.

And if you are not using hardware protection, then the invariance is
only notional as  D can call C, and C allows me access to pointers. And
once I have one of those, I can scribble anywhere that isn't hardware
protected.

All this smacks of D reinventing, with all the same mistakes, the whole
Java String vs. StringBuffer dichotomy:

    http://www.javaworld.com/javaworld/jw-03-2000/jw-0324-javaperf.html

And Java had the VM to isolate it from non-complient code.

One of several "mission statements" that drew me to D when I forst
encountered it nearly 3 years ago, was the pragmatism embodied in
articles like this:

    http://www.digitalmars.com/d/2.0/builtin.html

and this:

    http://www.digitalmars.com/d/2.0/cppstrings.html

and statements like this:

    "No pointless wrappers around C runtime library functions or OS API
functions D provides direct access to C runtime library functions and
operating system API functions. Pointless D wrappers around those
functions just adds blather, bloat, baggage and bugs."

Coming back to try and use D after a prolonged absence, the changes in
the interim period seem to be eshewing that pragmatism in favour of
some kind of mixed OO/functional purity ethic. Is there an ex-Haskeller
in the house?

I admit openly to still being in the throws of finding my way around
the language and the library, and have being making seemingly
elementary mistakes in interpreting the documentation. But one of the
major attractions of D over C/C++ is its built-in string types and
manipulations. As good as these are, there is still the need for a
library of common operations upon them. If everytime I want to use one
of these library calls, I have to cast my mutable string into and
invariant and then cast the result back to mutable inorder to be able
to use the built-in manipulations, lifes going to get very boring, very
fast.

The alternative I guess is to sit down and write my own library that
performs the same operations as std.string, but on the native string
type. Which kinda dilutes the purpose of having standard libraries.


Sorry to be so verbose, and please don't anyone take any of this
personally. I'm critiquing the code I am encountering, and the problems
I am having using it. Not the prople who wrote it.

Cheers, b.
--