Re: [fpc-pascal] := overload with implicit arrays in generics
Did anyone have any idea about this or should I just file a bug report for now? I don’t want to forget about it if possible. > On Jun 2, 2018, at 1:05 PM, Ryan Joseph wrote: > > type > generic TMyCollection = record >class operator := (values: array of T): TMyCollection; > end; > > class operator TMyCollection.:= (values: array of T): TMyCollection; > begin > end; > > var > c: specialize TMyCollection; > begin > c := ['aaa', 'bbb', 'ccc’]; // Ordinal expression expected Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
Mark Morgan Lloyd 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 non-mathematical 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 > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
denisgolovan schrieb am Sa., 2. Juni 2018, 10:28: > Yes, I strongly support removing that functionality in favor of user > operator overloads or vector-compatible 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 > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> Sven Barth via fpc-pascal hat am 2. Juni > 2018 um 09:42 geschrieben: > > denisgolovan < denisgolo...@yandex.ru> 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C# stackalloc
On 06/02/2018 02:01 AM, Ryan Joseph wrote: So it looks like my idea wasn’t that crazy after all. ;) just because more than one person comes up with the same or similar idea does not mean that it is not crazy or worse ;) ;) ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
On 02/06/18 08:00, Ryan Joseph wrote: On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal 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? typeTArrayOfInteger = array of integer; operator + (left: TArrayOfInteger; right: integer): TArrayOfInteger;var i: integer;beginfor 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 non-mathematical 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] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
Yes, I strongly support removing that functionality in favor of user operator overloads or vector-compatible way. Moreover, SSE/AVX vector extensions also should work per-element. I mean those vectors as in https://bugs.freepascal.org/view.php?id=27870 BR, Denis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
It's technically possible. But for vector operations to be valid/consistent both of them should work the same way. That is perform arithmetic per-element addition. BTW, you first overload is not implemented properly. You need to clone "left" first and return it as a result. BR, Denis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C# stackalloc
> On Jun 2, 2018, at 2:54 PM, Michael Van Canneyt > wrote: > > Personally, I don't understand the obsession with language features. > If anything, I would make the language more simple. But this is just me > swimming against the current. Ironically I totally agree but it’s so difficult to determine what is “necessary” and what isn’t. Sometimes it takes 10 years of real world implementation to realize something was a bad idea. Were there people that argued against operator overloads and advanced records I wonder? Those I’m 100% certain were good ideas and really make my life better. I'm even suspect of generics even though I use them often. I don’t use dynamic arrays but others here seem really attached to them. Even with all the language cruft at least FPC doesn’t force any of it on you like C# forces you to use classes for everything and denies you from allocating stuff on the stack. That’s where it crosses a very real line for me. You can still make procedural program and be totally oblivious to everything that happened in the last 20 years. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C# stackalloc
On Sat, 2 Jun 2018, Ryan Joseph wrote: On Jun 2, 2018, at 1:44 PM, Michael Van Canneyt wrote: 2 remarks: 1. It's only for arrays 2. It's for fixed-length arrays So you can do this in FPC today. Thirdly, you have objects which can be allocated on the stack, or advanced records. Plenty of choice for you. yes indeed. It’s just interesting because “stackalloc” basically swaps the memory backend and there’s a precedent for such a thing happening and in a very popular language. The hacker in me wants to play around with that idea in FPC to see what emerges. If management operators stick around there’s lots of potential to make advanced records a strong alternative. Best feature added to FPC is a while IMO so hopefully they survive the drama. :) People have come and went. But the features have always remained. They may receive more or less TLC of course. Personally, I don't understand the obsession with language features. If anything, I would make the language more simple. But this is just me swimming against the current. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal > 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
denisgolovan 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. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> On Jun 2, 2018, at 2:17 PM, denisgolovan wrote: > > Same here. > > The semantics for vector operations on arrays was thoroughly explored in > vector languages (APL, A+, J, K, etc). > Doing per-element 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C# stackalloc
> On Jun 2, 2018, at 1:44 PM, Michael Van Canneyt > wrote: > > 2 remarks: > 1. It's only for arrays > 2. It's for fixed-length arrays > > So you can do this in FPC today. > > Thirdly, you have objects which can be allocated on the stack, or advanced > records. > > Plenty of choice for you. yes indeed. It’s just interesting because “stackalloc” basically swaps the memory backend and there’s a precedent for such a thing happening and in a very popular language. The hacker in me wants to play around with that idea in FPC to see what emerges. If management operators stick around there’s lots of potential to make advanced records a strong alternative. Best feature added to FPC is a while IMO so hopefully they survive the drama. :) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> 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 per-element 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] C# stackalloc
On Sat, 2 Jun 2018, Ryan Joseph wrote: As a sanity check for myself if you remember a while ago I posted about an idea for “stack aliases” to override the memory allocation for classes. No one really liked the idea and lots of potential safety concerns were raised (fair criticisms). By random chance today I came upon this feature of C# which basically does the same thing I was suggesting, as a way to override the default functionality of C# to allocate everything on the heap and garbage collect later. The reason stated for the feature is because it’s an optimization over the default heap-only allocation enforced for arrays. So it looks like my idea wasn’t that crazy after all. ;) Granted C# needs this feature more than FPC does because C# amazingly can’t allocate arrays on the stack otherwise (now that’s crazy!) but never the less the inclusion of “stackalloc” in C# gives the idea some credibility for FPC. https://www.c-sharpcorner.com/uploadfile/GemingLeader/creating-a-stack-based-array/ 2 remarks: 1. It's only for arrays 2. It's for fixed-length arrays So you can do this in FPC today. Thirdly, you have objects which can be allocated on the stack, or advanced records. Plenty of choice for you. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
> On Jun 2, 2018, at 1:35 PM, Nitorami 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: Dynamic array extensions
>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://free-pascal-general.1045716.n5.nabble.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] C# stackalloc
As a sanity check for myself if you remember a while ago I posted about an idea for “stack aliases” to override the memory allocation for classes. No one really liked the idea and lots of potential safety concerns were raised (fair criticisms). By random chance today I came upon this feature of C# which basically does the same thing I was suggesting, as a way to override the default functionality of C# to allocate everything on the heap and garbage collect later. The reason stated for the feature is because it’s an optimization over the default heap-only allocation enforced for arrays. So it looks like my idea wasn’t that crazy after all. ;) Granted C# needs this feature more than FPC does because C# amazingly can’t allocate arrays on the stack otherwise (now that’s crazy!) but never the less the inclusion of “stackalloc” in C# gives the idea some credibility for FPC. https://www.c-sharpcorner.com/uploadfile/GemingLeader/creating-a-stack-based-array/ Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] := overload with implicit arrays in generics
Is this is a bug or am I not doing something right? I wanted to assign an implicit array (I think thats what those parameters are being called now) so I made an overload but the compiler is complaining. Using single characters gives a different error because the compiler thinks it’s an array of char instead of array of string. type generic TMyCollection = record class operator := (values: array of T): TMyCollection; end; class operator TMyCollection.:= (values: array of T): TMyCollection; begin end; var c: specialize TMyCollection; begin c := ['aaa', 'bbb', 'ccc’]; // Ordinal expression expected Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
