Suggestion: dynamic array operations

[Steve Horne]

On Wed, 06 Sep 2006 20:04:29 +0400, "Nikita Kalaganov"
<sapfirnik at rambler.ru> wrote:

>
>1. Pop from array on front/back
>
>Syntax:
...
>	ARRAY1 = ARRAY2 >>> INTEGER
>	ARRAY1 >>>= INTEGER


I think additional built-in methods for array types would be the best
solution for your problems.

'Push' and 'pop' are as clear as it gets. I don't find the C++ STL
push_back and push_front very intuitive - which end is the front? -
but, since I mentally lay out my subscripts the same as my cartesian
co-ordinates, push_left and pop_left work for me. And rotate methods
for arrays strike me as a very rare requirement, but what the hell ;-)


As for your operators, for one thing, the ones above already exist. D
has both signed and unsigned bitshift right operators. Don't ask me
why - I don't see the problem with shifting consistently with the
datatype, as C and C++ do.

Mind you, operators can be overloaded. I may be in a minority around
here, given that D has chosen a different route for I/O, but
personally I like the way that C++ overloads the << operator as
'stream insertion'. And I have no problem with the idea of extending
that so a 'stream' is any sequence of items. On that basis, why not...

  array1 << value-to-push;
  array2 >> var-to-pop-into;

Well, there is that little problem I have. While I like C++ stream
insertion, stream extraction is something else. It reads wrong.

Also, this goes against the flow of what D already defines. Pushing a
new item can already be done with...

  array1 ~= value-to-push;

D already defines all those wierd relative operators that handle NAN
for floats, so maybe there's room for taking '!' as 'opposite-of'
rather than just 'not'...

  array1 !~= var-to-pop;

But a major issue I have with that is that the item that is assigned
is the right hand argument, not the usual left hand argument that is
traditionally assigned by all C/C++/D/etc assignment operators.

Which goes back to the problem I have with stream extraction. If it
was written as...

  var-to-pop-into << array1;

or...

  var-to-pop-into <<= array1;

I would have less of a problem. And, as with multi-assignment
expressions, I would have less of a problem with...

  var1 << var2 << var3 << array1;

It reads better, to my eyes. It suggests items flowing out of the
array until the required number have flowed out, into the specified
slots. Beads sliding down string or something like that. The C++
stream extraction form...

  array1 >> var1 >> var2 >> var3;

Seems to suggest the same flow-like system, but the implied order is
the opposite of what actually happens.

But using the same '<<' or '<<=' or whatever for both means that it is
down to overload resolution to decide whether to insert or extract. If
the left argument is a 'stream', insert. If the right argument is a
'stream', extract. But if a 'stream' is just taken as referring to any
sequential data, what about arrays of arrays? What does the following
mean?

  varname << stringvar;

Is it inserting a string into an array of strings? Is it extracting a
character from a string?  For that matter, is it concatenating two
strings?

Overloading can resolve it. If you are inserting or extracting, the
types are different. Only concatenation has both arguments the same
type. But it isn't just the compiler that has to resolve the
overloading.

Basically, you have an operator with three clearly different meanings
(not including the bitshifting). Operator overloading was invented to
allow operators with a consistent meaning to work with new types - for
example, supporting '+' on new numeric types (perhaps decimal floats,
rationals) that the language doesn't have built in. It just seems a
bit too cryptic. Though you could claim that the meaning of '<<' was
something to do with flowing or shifting in general.

Also, I don't think deque operations and rotations are done often
enough to justify an operator. For example, those matrix algorithms of
yours should be written once and packaged in a library. Methods aren't
that much of a hardship.

But then, I already think the D relative operators are a bit nuts.
You'd have to be using floating point and caring about NAN a lot to
get used to them. Short of that, any gains from clutter clearing are
going to be lost referring back to the manuals. But there are
obviously people around who see it differently.

-- 
Remove 'wants' and 'nospam' from e-mail.