performance of concatenating 1 item to an array - repeatedly

[marcov]

Why do we need an operator in the first place? It doesn't happen that much, so pseudo functional syntax (intrinsic) that can be overloaded would be ok too.

If not, then I vote for a textual operator (like and/or/xor) rather than a single char one. It is the pascal way.

[PascalDragon]

Why do we need an operator in the first place? It doesn't happen that much, so pseudo functional syntax (intrinsic) that can be overloaded would be ok too.

Or one could use a type helper. Not everything needs to be an operator after all...

[circular]

In MacPas mode the pipe character is already used for short circuit or (and the ampersand is used for short circuit and; please note that this does not contradict my previous post as in MacPas mode the identifier escape using the ampersand is disabled).

Ok. That makes sense.

In a way, concatenating arrays is a bit like merging sets except that we keep double entries. So it is a bit like "or".

If not, then I vote for a textual operator (like and/or/xor) rather than a single char one. It is the pascal way.

Agreed.

We could use "or" to concatenate two arrays, though "or" could be applied to each component so we have the ambiguity again.

We don't need a new operator for everything, that's true. I guess the problem is more about the ambiguity of "+". It means "add" and "concatenate". The idea that it means "concatenate" comes from the string type of course. We don't want to add characters, so using "+" in this case is ok. But generalizing from there gives the ambiguity.

In fact there is Concat function to concatenate. Maybe we can just use that to concatenate arrays.

[winni]

Hi!

The concat intrinsic is the original Pascal syntax.

string := string + string;

is a lousy idea of Turbo Pascal stolen from basic.

Indeed concat should be enhanced to work for arrays.

Winni

[Thaddy]

In a way, concatenating arrays is a bit like merging sets except that we keep double entries. So it is a bit like "or"

No it is not like or. Or operates on the same memory space. Concatenation requires a copy operation and a memory expansion operation.
That is inherently different.

[Thaddy]

Indeed concat should be enhanced to work for arrays.

Already done:

Code: Pascal  [Select][+][-]

1. {$mode objfpc}
2. var
3.   a:array of integer = (1,2,3); // mode delphi requires square brackets, [ ]
4.   b:array of integer = (4,5,6); // but also works with concat()
5.   i:integer;
6. begin
7.   a := concat(a,b);
8.   for i in a do write(i);
9. end.

Requires 3.2.0+ I believe. The above is trunk. It might even work in 3.0.4, but I have no install to test it available at the moment.
Fixed arrays: I don't know if that's a good idea..

[winni]

Hi!

Yes, fpc 3.04 refuses to compile:

Code: Text  [Select][+][-]

1. gridtest1.pas(100,15) Error: Incompatible types: got "{Dynamic} Array Of LongInt" expected "ShortString"

But good to hear that there is progress.

Winni

[circular]

Indeed that's good news.

No it is not like or. Or operates on the same memory space. Concatenation requires a copy operation and a memory expansion operation.

I understand your point but do you understand mine?

[Thaddy]

Yes, fpc 3.04 refuses to compile:

Announcement is for 3.2.0 indeed. See https://wiki.freepascal.org/FPC_New_Features_3.2.0#Dynamic_Arrays_supported_by_Concat.28.29
So it is actually finished....

[PascalDragon]

Please note that in FPC 3.2 and newer in mode Delphi or if modeswitch ArrayOperators is set the + operator is the same as Concat (and can't be overloaded anymore). This together with Concat for dynamic arrays is also mentioned here.

[Thaddy]

Indeed that's good news.

No it is not like or. Or operates on the same memory space. Concatenation requires a copy operation and a memory expansion operation.

I understand your point but do you understand mine?

Not really. or is in my view strictly limited and different from addition.

[circular]

Not really. or is in my view strictly limited and different from addition.

Doesn't need to be limited.

Or is like a set union where each bit is an element of the set. And a set can be represented as an array (sorted and without duplicates).

[MarkMLl]

Or is like a set union where each bit is an element of the set. And a set can be represented as an array (sorted and without duplicates).

I don't think that Pascal defines a set as being ordered: you can apply Pred() and Succ() to the base type, but that doesn't translate to LeftOf() and RightOf() applied to the set.

Modula-2 has a bitset which is defined as mapping onto the machine word, but even there the ordering was inconsistent.

In any event, the whole point of a set is that the  or  etc. operations are efficient: an implementation based on an array which was possibly-occasionally re-sorted and de-duplicated is an abomination.

MarkMLl

[circular]

I feel your sense of horror in terms of implementation.

Though that was not the subject, I was talking about the subject from a mathematical point of view:

Or = Union
And = Intersection

[MarkMLl]

With the caveat that mathematics has a hard time keeping up with some things that are basic to programming, hence absurdities such as https://en.wikipedia.org/wiki/Collatz_Conjecture#Iterating_on_real_or_complex_numbers

MarkMLl