
12345

> ## "+" operator
> The compiler now implements a "+" operator for arrays which is the same
> as if Concat() would be called on the arrays.
> Note regarding backwards compatibility: existing "+" operator overloads
> for dynamic arrays no longer compile.
Are you serious ? I have been using dynamic arrays a lot for processing of
vectors and matrices containing floating point values, and implemented the +
operator to do the obvious, add the elements of two vectors, NOT to concat
them. This is just natural for floating point vectors, similar as with other
basic mathemetical operators as *,, /.
Even if the "+" has always been used to concat strings, I find it a really
really bad idea to extend that to danymic arrays.

Sent from: http://freepascalgeneral.1045716.n5.nabble.com/_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 2, 2018, at 5:19 AM, Nitorami < [hidden email]> wrote:
>
> Are you serious ? I have been using dynamic arrays a lot for processing of
> vectors and matrices containing floating point values, and implemented the +
> operator to do the obvious, add the elements of two vectors, NOT to concat
> them. This is just natural for floating point vectors, similar as with other
> basic mathemetical operators as *,, /.
> Even if the "+" has always been used to concat strings, I find it a really
> really bad idea to extend that to danymic arrays.
Why are you using dynamic arrays for vectors/matricies? If what you have is an actual array you wish to grow then + would likely be an append operation.
var
v: TVec2;
begn
v := V2(1,1);
v += 10; // add 10 to x/y and get: v = 11,11
var
v: array of float;
begn
SetLength(v, 1);
v[0] := 1;
v += 10; // append 10 and get : v = 1,10
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


>Why are you using dynamic arrays for vectors/matricies? If what you have is
an actual array you wish to grow then + would likely be an append operation.
Dynamic arrays are incredibly convenient for purposes like signal processng,
whe you need to handle large blocks of numeric data in variable size. What
an annoyace that was in times of turbo pascal, when I had to fuff with
pointers, and use procedures for simple mathametical operations. With FPC
that was all gone, and I can now handle vectors the same as simple numbers.
Just like matlab does: a=bxc provides the expected result regardless whether
the variables are scalars, vectors or matrices.
I strongly disagree with the opionon that "+" is natural to be the append
operation. That may be true for strings, where it is the *only * useful
operator. But for numeric vectors, *all * mathematical operators +*/ are
meaningful, and it is madness to steal one of them just for conatenation,
and to obliterate all other operators for use with dynamic arrays at the
same time. Obviously, if I cannot use "+", I can throw all others into the
bin as well, but rather think of a different concept using procedures, like
I am back in the 90s with turbo pascal.
By all means, please reconsider this, and leave me the choice to define the
operators. If I want "+" for concatting, it is trivial to define it myself.
I don't need the language to force that and eseentially destroy operator
overloading for mathematical operations on dynamic arrays.

Sent from: http://freepascalgeneral.1045716.n5.nabble.com/_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 2, 2018, at 1:35 PM, Nitorami < [hidden email]> wrote:
>
> I strongly disagree with the opionon that "+" is natural to be the append
> operation.
Not even in the context of a list? I’m still not sure what exactly the operations you are doing but it sounds like you have a vector of numbers and you want to overload + so you can add to the value of all numbers. That makes perfect sense but it’s in conflict with the other (more common) use of arrays.
Why aren’t you using a class or record and making a custom data type btw?
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> By all means, please reconsider this, and leave me the choice to define the
> operators. If I want "+" for concatting, it is trivial to define it myself.
> I don't need the language to force that and eseentially destroy operator
> overloading for mathematical operations on dynamic arrays.
Same here.
The semantics for vector operations on arrays was thoroughly explored in vector languages (APL, A+, J, K, etc).
Doing perelement dyadic function application is the basis for it. Having proper operators overloads is crucial.
@Sven
Please reconsider "+" operator for arrays if your changes really forbid to overload operators for arrays now.
Regards,
Denis Golovan
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 2, 2018, at 2:17 PM, denisgolovan < [hidden email]> wrote:
>
> Same here.
>
> The semantics for vector operations on arrays was thoroughly explored in vector languages (APL, A+, J, K, etc).
> Doing perelement dyadic function application is the basis for it. Having proper operators overloads is crucial.
>
> @Sven
> Please reconsider "+" operator for arrays if your changes really forbid to overload operators for arrays now.
Why not make a record for vectors that has a dynamic array backend? Then you can add all the methods and various operators you want. That of course doesn’t help for legacy code bases that sound like they’re going to be broken.
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


@Sven
Please reconsider "+" operator for arrays if your changes really forbid to overload operators for arrays now.
It wasn't me who implemented that part. I personally had planned to do it with a warning for existing overloads, but Florian beat me to it and implemented it this way. Though when asked by me he did say that we'll wait and see if people complain... So *maybe* we'll change this.
Regards, Sven
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 2, 2018, at 2:42 PM, Sven Barth via fpcpascal < [hidden email]> wrote:
>
> It wasn't me who implemented that part. I personally had planned to do it with a warning for existing overloads, but Florian beat me to it and implemented it this way. Though when asked by me he did say that we'll wait and see if people complain... So *maybe* we'll change this.
>
btw why can’t there be both? You can have multiple + operators for any given dynamic array type can’t you?
type
TArrayOfInteger = array of integer;
operator + (left: TArrayOfInteger; right: integer): TArrayOfInteger;
var
i: integer;
begin
for i := 0 to high(left) do
left[i] += 1;
end;
operator + (left: TArrayOfInteger; right: TArrayOfInteger): TArrayOfInteger;
begin
result := Concat(left, right);
end;
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


It's technically possible.
But for vector operations to be valid/consistent both of them should work the same way. That is perform arithmetic perelement addition.
BTW, you first overload is not implemented properly. You need to clone "left" first and return it as a result.
BR,
Denis
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


On 02/06/18 08:00, Ryan Joseph wrote:
>> On Jun 2, 2018, at 2:42 PM, Sven Barth via fpcpascal < [hidden email]> wrote:> > It wasn't me who implemented that part. I personally had planned to do it with a warning for existing overloads, but Florian beat me to it and implemented it this way. Though when asked by me he did say that we'll wait and see if people complain... So *maybe* we'll change this.>
> btw why can’t there be both? You can have multiple + operators for any given dynamic array type can’t you?
> type TArrayOfInteger = array of integer;
> operator + (left: TArrayOfInteger; right: integer): TArrayOfInteger;var i: integer;begin for i := 0 to high(left) do left[i] += 1;end;
> operator + (left: TArrayOfInteger; right: TArrayOfInteger): TArrayOfInteger;begin result := Concat(left, right);end;
Agreed, both are extremely useful and have an intuitively unambiguous
meaning (unlike  which can be useful but doesn't have an unambiguous
meaning).
However as Dennis points out + is also essential for vector operations.
Perhaps either leaving it to the programmer to define what's needed
would be the best approach, or alternatively splitting dynamic arrays
into mathematical vectors and nonmathematical collections. Or relaxing
the requirement that only predefined operators can be redefined, so that
something like _ could be used for concatenation.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


In reply to this post by Free Pascal  General mailing list
> Sven Barth via fpcpascal < [hidden email]> hat am 2. Juni 2018 um 09:42 geschrieben:
>
> denisgolovan < [hidden email]> schrieb am Sa., 2. Juni 2018, 09:18:
> > @Sven
> > Please reconsider "+" operator for arrays if your changes really forbid to overload operators for arrays now.
>
>
> It wasn't me who implemented that part. I personally had planned to do it with a warning for existing overloads, but Florian beat me to it and implemented it this way. Though when asked by me he did say that we'll wait and see if people complain... So *maybe* we'll change this.
+1 for the possibility to overload this operator.
Mattias
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


Yes, I strongly support removing that functionality in favor of user operator overloads or vectorcompatible way.
To clear something up: this new operator will definitely not be removed. Period.
What might be done however (and what I had planned) is that existing overloads of the "+"operator take precedence to the internal operator.
Though I wouldn't mind introducing a syntax that can be used to force a element wise operation on a array. This way one wouldn't need to do the overload for the array, but the compiler would pick the operator of the element type instead.
Regards, Sven
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


Mark Morgan Lloyd < [hidden email]> schrieb am Sa., 2. Juni 2018, 10:53: However as Dennis points out + is also essential for vector operations.
Perhaps either leaving it to the programmer to define what's needed
would be the best approach, or alternatively splitting dynamic arrays
into mathematical vectors and nonmathematical collections. Or relaxing
the requirement that only predefined operators can be redefined, so that
something like _ could be used for concatenation.
That needlessly complicates the parser as the compiler still needs to know them and they also need to be part of its operator precedence rules. Don't complicate the language for nothing! And in the end operator overloads are one of the best examples for syntactic sugar as you can easily achieve the same result with functions and methods.
Regards, Sven
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 2, 2018, at 3:19 PM, denisgolovan < [hidden email]> wrote:
>
> BTW, you first overload is not implemented properly. You need to clone "left" first and return it as a result.
That’s probably the functionality you want but as an aside why can’t + overload mutate the caller (left side) and not return anything?
I would expect there to an operator like below in addition to the usual that returns the left side and assigns to the left aside on return.
class operator + (var left: TIntArray; const right: T);
if you’re appending to an array for example:
a += 1;
why should the compiler return the array (a) and then copy it back to the caller in the same place? It’s a just a waste and if the caller is a record it could be costly.
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 2, 2018, at 3:19 PM, denisgolovan <[hidden email]> wrote:
>
> BTW, you first overload is not implemented properly. You need to clone "left" first and return it as a result.
That’s probably the functionality you want but as an aside why can’t + overload mutate the caller (left side) and not return anything?
Because operator overloads are static methods not normal methods.
Regards, Sven
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


In reply to this post by Free Pascal  General mailing list
> On Jun 3, 2018, at 3:15 PM, Sven Barth via fpcpascal < [hidden email]> wrote:
>
> Because operator overloads are static methods not normal methods.
I don’t understand. Why aren’t both those variants possible? They’re both static I believe. The first is mutating the left side value and the second is a clone (the most common operation for += )
class operator + (var left: TIntArray; const right: T);
class operator + (constref left: TIntArray; const value: T): TIntArray;
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


In reply to this post by Free Pascal  General mailing list
Am 02.06.2018 um 15:14 schrieb Sven
Barth via fpcpascal:
Mark Morgan Lloyd < [hidden email]>
schrieb am Sa., 2. Juni 2018, 10:53:
However as
Dennis points out + is also essential for vector operations.
Perhaps either leaving it to the programmer to define what's
needed
would be the best approach, or alternatively splitting
dynamic arrays
into mathematical vectors and nonmathematical collections.
Or relaxing
the requirement that only predefined operators can be
redefined, so that
something like _ could be used for concatenation.
That needlessly complicates the parser as the
compiler still needs to know them and they also need to be
part of its operator precedence rules. Don't complicate the
language for nothing! And in the end operator overloads are
one of the best examples for syntactic sugar as you can easily
achieve the same result with functions and methods.
Regards,
Sven
This is somehow off topic of course,
but IMO it is strange to use + for string concatenation;
I always have bad feelings about this. This whole thread would
not exist, if FreePascal had gone another direction like PL/1, for
example,
where the string concatenation operator is 
(and DB2, and  probably  other SQL dialects).
Where does this + for string concat come from?
(Of course,  has some codepage issues, but that's another story,
and it means logical or in other languages ...)
BTW:
this is (part of) the input for the scanner generator
for the New Stanford Pascal compiler:
SYLPARENT := '(';
SYRPARENT := ')';
SYLBRACK := '[' OR '(.' OR '(/';
SYRBRACK := ']' OR '.)' OR '/)';
SYCOMMA := ',';
SYSEMICOLON := ';';
SYARROW := '>' OR '@' OR '^';
SYPERIOD := '.';
SYDOTDOT := '..';
SYCOLON := ':';
SYPLUS := '+';
SYMINUS := '';
SYMULT := '*';
SYSLASH := '/';
SYEQOP := '=';
SYNEOP := '<>';
SYGTOP := '>';
SYLTOP := '<';
SYGEOP := '>=';
SYLEOP := '<=';
SYOROP := '';
SYANDOP := '&';
SYASSIGN := ':=';
SYCONCAT := '';
if you want to change the representation of the symbols, you only
change here.
Kind regards
Bernd
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal


> On Jun 3, 2018, at 4:56 PM, Bernd Oppolzer < [hidden email]> wrote:
>
> but IMO it is strange to use + for string concatenation;
> I always have bad feelings about this.
It’s actually pretty common to use the phrase “adding two things together” in English. For example: “I’m going to add some more strawberries to my milkshake”, or, “add this to my list of things to do”. Maybe it’s a language thing but adding is certainly pretty typical for the idea of concatenation.
Regards,
Ryan Joseph
_______________________________________________
fpcpascal maillist  [hidden email]
http://lists.freepascal.org/cgibin/mailman/listinfo/fpcpascal

12345
