Feature announcement: Dynamic array extensions

classic Classic list List threaded Threaded
94 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
Hello together!

I'm pleased to announce that after nearly a year various extensions for
dynamic arrays have been finished. This includes the following features:

- support for array constructors using "[...]" syntax
- support for Insert(), Delete() and Concat()
- support for "+" operator
- support for dynamic array constants (and variable initializations)

In the following the features will be explained in detail:

## Array Constructors

It is now possible to initialize a dynamic array variable or parameter
using the "[...]" which is also known from open array parameters. Unlike
the ArrayType.Create() syntax which had been introduced with 3.0 this
also works with unnamed array types. Nested dynamic arrays are also
supported.

=== code begin ===

var
   t: array of LongInt;
   t2: array of array of LongInt;
begin
   t := [1, 2, 3, 4];
   t2 := [[1, 2, 3], [4, 5]];
end.

=== code end ===

## Insert(), Delete(), Concat()

The intrinsics Insert(), Delete() and Concat() can now be used with
dynamic arrays as well.

Insert() allows to insert a single element, a dynamic array or a static
array into a dynamic array at a specific index (zero based). If the
dynamic array is empty it will simply contain the content to be
inserted. If the index to insert is larger than the array's High() then
the content will be added at the end.

Delete() allows to remove a range of elements from a dynamic array (the
start index is zero based). The range will be capped to the array's
boundaries.

Concat() allows to concatenate two (or more) dynamic arrays together.
The second array content starts directly after the first and those of
the third after the second and so on.

## "+" 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.

## Dynamic array constants

It is now possible to initialize dynamic array constants and variables
with concrete contents in contrast to merely Nil. The syntax for this is
the same as for static array constant and variable initializations.

=== code begin ===

const
   Test1: array of LongInt = (1, 2, 3);
var
   Test2: array of String = ('Alpha', 'Beta', 'Gamma');

=== code end ===

For constants the dynamic array constants adhere to the writable
constants switch $J. E.g. the following will result in an exception:

=== code begin ===

{$J-}
const
   Test1: array of LongInt  = (1, 2, 3);
begin
   Test1[1] := 42;
end.

=== code end ===

It is possible to nest dynamic and static array constants.

Delphi compatibility:

- in Delphi modes the syntax for dynamic array constant and variable
initialization is "[...]" instead of "(...)"
- Delphi does not adhere to the writable constants switch regarding the
array's contents (so the example above - when adjusted for Delphi's
syntax - will not result in an exception)
- Delphi does not correctly parse static array constants inside dynamic
arrays; as we don't know what the syntax would be for Delphi then, this
is prohibited in Delphi modes

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Michael Van Canneyt


On Sun, 20 May 2018, Sven Barth via fpc-pascal wrote:

> Hello together!
>
> I'm pleased to announce that after nearly a year various extensions for
> dynamic arrays have been finished. This includes the following features:
>
> - support for array constructors using "[...]" syntax
> - support for Insert(), Delete() and Concat()
> - support for "+" operator
> - support for dynamic array constants (and variable initializations)
>

Congratulations, job well done. This makes life a lot easier !

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Mattias Gaertner
In reply to this post by Free Pascal - General mailing list
On Sun, 20 May 2018 14:23:25 +0200
Sven Barth via fpc-pascal <[hidden email]> wrote:

> Hello together!
>
> I'm pleased to announce that after nearly a year various extensions for
> dynamic arrays have been finished. This includes the following features:
>
> - support for array constructors using "[...]" syntax
> - support for Insert(), Delete() and Concat()
> - support for "+" operator
> - support for dynamic array constants (and variable initializations)

:)

I hope 3.2 is coming soon.


>[...]
> === code end ===
>
> For constants the dynamic array constants adhere to the writable
> constants switch $J. E.g. the following will result in an exception:
>
> === code begin ===
>
> {$J-}
> const
>    Test1: array of LongInt  = (1, 2, 3);
> begin
>    Test1[1] := 42;
> end.

This seems to be inconsistent with

procedure Test(const a: TStringDynArray);
begin
  a[1]:='42';
end;

Isn't it?
 
Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Michael Van Canneyt


On Sun, 20 May 2018, Mattias Gaertner wrote:

> On Sun, 20 May 2018 14:23:25 +0200
> Sven Barth via fpc-pascal <[hidden email]> wrote:
>
>> Hello together!
>>
>> I'm pleased to announce that after nearly a year various extensions for
>> dynamic arrays have been finished. This includes the following features:
>>
>> - support for array constructors using "[...]" syntax
>> - support for Insert(), Delete() and Concat()
>> - support for "+" operator
>> - support for dynamic array constants (and variable initializations)
>
> :)
>
> I hope 3.2 is coming soon.
>
>
>> [...]
>> === code end ===
>>
>> For constants the dynamic array constants adhere to the writable
>> constants switch $J. E.g. the following will result in an exception:
>>
>> === code begin ===
>>
>> {$J-}
>> const
>>    Test1: array of LongInt  = (1, 2, 3);
>> begin
>>    Test1[1] := 42;
>> end.
>
> This seems to be inconsistent with
>
> procedure Test(const a: TStringDynArray);
> begin
>  a[1]:='42';
> end;
>
> Isn't it?
The const in the parameters indicates that the pointer a cannot be assigned,
but the contents can be assigned when inside the procedure.
(we can discuss whether this behaviour is logical, but I suppose we
inherited this from Delphi)

Whereas a constant is something that is eternally constant throughout the
application. Normally, a constant is something that is replaced by its
value when the compiler encounters it the sources.

So in a sense, it does not exist at runtime, hence you cannot assign to it
either.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Anthony Walter-3
In reply to this post by Free Pascal - General mailing list
Holy crap Sven. This is so awesome! I was going to write a request last week to allow for a simplified array constant declaration, and you've already got it done.

Thanks for your work. I'll test it momentarily and report any actual problems to Mantis.

By the way, what's the reason for differences in () / [] syntax between objpas and delphi mode?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Anthony Walter-3
I just got fpc from svn trunk (http://svn.freepascal.org/svn/fpc/trunk/) and tested. Before I submit to Mantis, can you tell me if I made a mistake here?

program hello;

{$mode delphi}

procedure Test;
var
  Data: array of Integer = [0, 15, 24];
  I: Integer;
begin
  WriteLn('Testing new array features');
  for I in Data do
    WriteLn(Data[I]);
end;

begin
  Test;
end.

Outputs:

Testing new array features
0
0
-2235258

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Anthony Walter-3
Never mind, I found the problem.

program hello;

{$mode delphi}

procedure Test;
var
  Data: array of Integer = [0, 15, 24];
  I: Integer;
begin
  WriteLn('Testing new array features');
  for I in Data do
    WriteLn(I); // fixed
end;

begin
  Test;
end.

Outputs:

Testing new array features
0
15
24


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Anthony Walter-3
Anthony Walter <[hidden email]> schrieb am So., 20. Mai 2018, 19:09:
By the way, what's the reason for differences in () / [] syntax between objpas and delphi mode?

For the non-Delphi modes I decided to keep consistency with static array constants (which use the same syntax in Delphi btw!). For the Delphi modes I followed what Delphi does. And for some reason the Delphi devs thought it better to use a different syntax than that for static arrays. 🤷‍♀️

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Mattias Gaertner
Mattias Gaertner <[hidden email]> schrieb am So., 20. Mai 2018, 17:58:
>[...]
> === code end ===
>
> For constants the dynamic array constants adhere to the writable
> constants switch $J. E.g. the following will result in an exception:
>
> === code begin ===
>
> {$J-}
> const
>    Test1: array of LongInt  = (1, 2, 3);
> begin
>    Test1[1] := 42;
> end.

This seems to be inconsistent with

procedure Test(const a: TStringDynArray);
begin
  a[1]:='42';
end;

Isn't it?

But it is consistent with static array constants and that is what counts...

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Jesus Reyes A.
In reply to this post by Free Pascal - General mailing list
En Sun, 20 May 2018 07:23:25 -0500, Sven Barth via fpc-pascal  
<[hidden email]> escribió:

> Hello together!
>
> I'm pleased to announce that after nearly a year various extensions for  
> dynamic arrays have been finished. This includes the following features:
>
> - support for array constructors using "[...]" syntax
> - support for Insert(), Delete() and Concat()
> - support for "+" operator
> - support for dynamic array constants (and variable initializations)
>

Wow!
Thanks :)

Jesus Reyes A.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Maciej Izak
In reply to this post by Free Pascal - General mailing list
2018-05-20 20:44 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
Anthony Walter <[hidden email]> schrieb am So., 20. Mai 2018, 19:09:
By the way, what's the reason for differences in () / [] syntax between objpas and delphi mode?

For the non-Delphi modes I decided to keep consistency with static array constants (which use the same syntax in Delphi btw!). For the Delphi modes I followed what Delphi does. And for some reason the Delphi devs thought it better to use a different syntax than that for static arrays. 🤷‍♀️

Gratz, seems that I will need to update NewPascal soon to get this fresh feature :). 

They decide for [] probably because it is similar syntax like for open arrays. IMO "[]" syntax has more dynamic meaning/nature so looks more proper for this feature (as you said "()" syntax is used for static arrays), but this is probably individual taste.

"[]" also might be better for something like this :

var
  f: array of TSomeRec = [(a: 10; b: ['1', '2']), (a: 20; b: ['6'])];

instead of

var
  f: array of TSomeRec = ((a: 10; b: ('1', '2')), (a: 20; b: ('6')));

The main gain of different syntax between Delphi and ObjFpc is more troubles for Pascal Programmers. :(

Why you decide to prohibit static array constants inside dynamic array constants for Delphi modes in r39045? I do not understand this decision. It is some punishment for using Delphi mode? -,- IMO bad decision.

For the consequence the following code

var
  f: array of TSomeRec = [(a: 10; b: ['1', '2']), (a: 20; b: ['6'])];

should be also prohibited in Delphi mode, because it not works in Delphi like static array constants inside dynamic array constants...

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
Maciej Izak <[hidden email]> schrieb am So., 20. Mai 2018, 21:49:
Why you decide to prohibit static array constants inside dynamic array constants for Delphi modes in r39045? I do not understand this decision. It is some punishment for using Delphi mode? -,- IMO bad decision.

I prohibited it because Delphi does not support it correctly and I don't know whether they'd use the usual "(...)"-syntax for the static arrays or switch to the dynamic array one. To avoid potential backwards compatibility problems I decided to simply disallow it. And to be fair: how often do you declare dynamic arrays that consist of static arrays? 

For the consequence the following code

var
  f: array of TSomeRec = [(a: 10; b: ['1', '2']), (a: 20; b: ['6'])];

should be also prohibited in Delphi mode, because it not works in Delphi like static array constants inside dynamic array constants...

I had not tested that one. In consequence that should indeed be disallowed as well. Though here the syntax probably wouldn't provide problems in the future. 

Regards, 
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Maciej Izak
2018-05-20 22:50 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
I prohibited it because Delphi does not support it correctly and I don't know whether they'd use the usual "(...)"-syntax for the static arrays or switch to the dynamic array one. To avoid potential backwards compatibility problems I decided to simply disallow it. 

I do not buy this ;) no one knows what they will use (if ever), but still I see no real reason for blocking this. Following yours logic any of management operators should be also prohibited in Delphi mode because some similar feature for nullable types is planned for Delphi (but no one knows the final form of their Initialize/Finalize equivalent). Code in r39045 is IMO too strict. 
 
I had not tested that one. In consequence that should indeed be disallowed as well. Though here the syntax probably wouldn't provide problems in the future. 

and the same sentence is true for the syntax for static array constants inside dynamic array constants, the more Delphied syntax for arrays probably wouldn't provide problems in the future too :) 

If you like very strict approach and you want to make our life simpler probably you should implement some "modeswitch" for allowing both examples (example with records and arrays).

btw. the problem for different syntax between Delphi and ObjFpc is still valid. I don't see any real gain for different syntax. It was consulted with community or this is just individual decision? (and here sorry if I overlooked something).

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
Maciej Izak <[hidden email]> schrieb am So., 20. Mai 2018, 23:32:
2018-05-20 22:50 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
I prohibited it because Delphi does not support it correctly and I don't know whether they'd use the usual "(...)"-syntax for the static arrays or switch to the dynamic array one. To avoid potential backwards compatibility problems I decided to simply disallow it. 

I do not buy this ;) no one knows what they will use (if ever), but still I see no real reason for blocking this. Following yours logic any of management operators should be also prohibited in Delphi mode because some similar feature for nullable types is planned for Delphi (but no one knows the final form of their Initialize/Finalize equivalent). Code in r39045 is IMO too strict. 

The thing is that I can easily imagine the Delphi devs to be so stoned to use the "[...]" for static arrays inside dynamic arrays as well which could lead to constructs like the following because they forget that dynamic arrays could be part of static arrays as well:

=== code begin ===

var
  v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3], [4, 5, 6]], [], [[7, 8, 9]]);

=== code end ===

Yes, I have absolutely no confidence in the Delphi developers. 

 
I had not tested that one. In consequence that should indeed be disallowed as well. Though here the syntax probably wouldn't provide problems in the future. 

and the same sentence is true for the syntax for static array constants inside dynamic array constants, the more Delphied syntax for arrays probably wouldn't provide problems in the future too :) 

If you like very strict approach and you want to make our life simpler probably you should implement some "modeswitch" for allowing both examples (example with records and arrays). 

I don't want to use a modeswitch for every tiny little bit of feature. What we could do however would be a modeswitch for a strict Delphi mode that prohibits extensions and code that does not work in Delphi (like global operators and global generic functions). This could be used for code that is shared with Delphi to avoid potentially breaking compilability with Delphi if one is mainly using FPC for testing. 


btw. the problem for different syntax between Delphi and ObjFpc is still valid. I don't see any real gain for different syntax. It was consulted with community or this is just individual decision? (and here sorry if I overlooked something) 

The gain is consistency with static array constants. You don't need to care about whether it's a dynamic array or a static one, you simply use the same syntax. 
Also what do you care about mode ObjFPC anyway? One purpose of the mode *is* that it can go a different route than those modes that copy existing implementations. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Maciej Izak
2018-05-21 0:52 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
The thing is that I can easily imagine the Delphi devs to be so stoned to use the "[...]" for static arrays inside dynamic arrays as well which could lead to constructs like the following because they forget that dynamic arrays could be part of static arrays as well:

=== code begin ===

var
  v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3], [4, 5, 6]], [], [[7, 8, 9]]);

=== code end ===

Yes, I have absolutely no confidence in the Delphi developers. 

Sometimes they have fantasy ^^. Don't underestimate them, I am sure they can do something more unexpected ;) For NewPascal mode I see this like :

var
  v: array[0..2] of array of array[0..2] of LongInt = ([(1, 2, 3), (4, 5, 6)], [], [(7, 8, 9)]);
 
I don't want to use a modeswitch for every tiny little bit of feature. What we could do however would be a modeswitch for a strict Delphi mode that prohibits extensions and code that does not work in Delphi (like global operators and global generic functions). This could be used for code that is shared with Delphi to avoid potentially breaking compilability with Delphi if one is mainly using FPC for testing.

IMO potentially breaking compatibility is better than lock/prohibition for missing features in Delphi (or waiting for Delphi implementation). Programmers are not stupid and most of Delphi users knows what Delphi have and what can be potentially risky. We have tons of examples which should be disabled in Delphi mode but it works for comfort. r39045 is for sure not comfortable IMO without real important reason, but this is just my opinion.
 
The gain is consistency with static array constants. You don't need to care about whether it's a dynamic array or a static one, you simply use the same syntax. 
Also what do you care about mode ObjFPC anyway? One purpose of the mode *is* that it can go a different route than those modes that copy existing implementations. 

I am worried about all Pascal modes including ObjFPC and Delphi mode. :)
 
--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
Am 21.05.2018 um 01:36 schrieb Maciej Izak:
2018-05-21 0:52 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
The thing is that I can easily imagine the Delphi devs to be so stoned to use the "[...]" for static arrays inside dynamic arrays as well which could lead to constructs like the following because they forget that dynamic arrays could be part of static arrays as well:

=== code begin ===

var
  v: array[0..2] of array of array[0..2] of LongInt = ([[1, 2, 3], [4, 5, 6]], [], [[7, 8, 9]]);

=== code end ===

Yes, I have absolutely no confidence in the Delphi developers. 

Sometimes they have fantasy ^^. Don't underestimate them, I am sure they can do something more unexpected ;) For NewPascal mode I see this like :

var
  v: array[0..2] of array of array[0..2] of LongInt = ([(1, 2, 3), (4, 5, 6)], [], [(7, 8, 9)]);
 

That is at least what I would *expect* for Delphi as well. And no, I'm definitely not underestimating their ability to come up with strange syntaxes... Do I do prefer not to think about it too much to avoid nightmares :P

I don't want to use a modeswitch for every tiny little bit of feature. What we could do however would be a modeswitch for a strict Delphi mode that prohibits extensions and code that does not work in Delphi (like global operators and global generic functions). This could be used for code that is shared with Delphi to avoid potentially breaking compilability with Delphi if one is mainly using FPC for testing.

IMO potentially breaking compatibility is better than lock/prohibition for missing features in Delphi (or waiting for Delphi implementation). Programmers are not stupid and most of Delphi users knows what Delphi have and what can be potentially risky. We have tons of examples which should be disabled in Delphi mode but it works for comfort. r39045 is for sure not comfortable IMO without real important reason, but this is just my opinion.

I've decided to lift the restriction again in r39078. Happy now?

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Mark Morgan Lloyd-5
In reply to this post by Free Pascal - General mailing list
On 20/05/18 12:30, Sven Barth via fpc-pascal wrote:

> ## "+" 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.

Does that only apply when both operands are compatible dynamic arrays,
or does it also break definition of + to append an element to an array?

--
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Jonas Maebe-3
In reply to this post by Maciej Izak
On 21/05/18 01:36, Maciej Izak wrote:
> IMO potentially breaking compatibility is better than lock/prohibition
> for missing features in Delphi (or waiting for Delphi implementation).

Breaking backwards compatibility is one of the the worst things you can
do in a programming language/compiler, and the primary concern when
making changes to a language should always be to avoid this (except when
you're developing a new language that's still in its infancy).

Even if you design everything with that mindset, you know that you will
still have to do it occasionally because you missed certain things or
could not foresee them. Especially since no one cares to formally
specify and analyse standards for Pascal anymore, so nothing gets vetted
properly. Those cases are enough, there is no need to intentionally add
more (even if only potential ones).

Breaking backwards compatibility wastes time (both of the developer that
has document the change and the users that have to adapt their —or
worse, other people's— code), wastes energy on friction (users annoyed
that their code no longer works, compiler developers annoyed that users
didn't read the changelog, noise on fora/mailing lists, extra bug
reports), and breaks the most fundamental expectation of using a high
level language (unambiguous/formally correct code that used to
compile/work should keep compiling/working; that's the whole point of
using a high level language).

Some of the above things can also happen if a particular feature is not
available in a certain language mode, but that is bound to the nature of
language modes: not all language modes provide the same features and/or
features in the same way.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Maciej Izak
2018-05-21 10:49 GMT+02:00 Jonas Maebe <[hidden email]>:
Breaking backwards compatibility is one of the the worst things you can do in a programming language/compiler, and the primary concern when making changes to a language should always be to avoid this (except when you're developing a new language that's still in its infancy).

Even if you design everything with that mindset, you know that you will still have to do it occasionally because you missed certain things or could not foresee them. Especially since no one cares to formally specify and analyse standards for Pascal anymore, so nothing gets vetted properly. Those cases are enough, there is no need to intentionally add more (even if only potential ones).

Breaking backwards compatibility wastes time (both of the developer that has document the change and the users that have to adapt their —or worse, other people's— code), wastes energy on friction (users annoyed that their code no longer works, compiler developers annoyed that users didn't read the changelog, noise on fora/mailing lists, extra bug reports), and breaks the most fundamental expectation of using a high level language (unambiguous/formally correct code that used to compile/work should keep compiling/working; that's the whole point of using a high level language).

Some of the above things can also happen if a particular feature is not available in a certain language mode, but that is bound to the nature of language modes: not all language modes provide the same features and/or features in the same way.

Generally I fully agree with that... Anyway Delphi mode/case is special. AFAIK all significant Delphi compiler developers are lay off. The progress for classic Delphi is almost dead and Delphi NEXTGEN totally breaks backward compatibility. 

We have interesting time : FPC Delphi mode with FPC RTL is more backward compatible with Delphi than new Delphi :).

I don't like the totally prohibition for all new things in Delphi mode, this is because not everyone is happy with ObjFPC and personally I prefer more Delphi syntax (XE2 level/features) but I want to have new features too (like fully working "Dynamic array extensions" without any prohibitions). I like to use some elements from Oxygene dialect (which probably can not be 100% ported into FPC). I have many voices abut this from community and many programmers agree with me.

The solution for keeping Delphi mode in right place and leave ObjFPC in FPC core hands, is new mode : NewPascal.

This was discussed few years ago that I will be able to do new mode when I will done few modeswitches, but now I am outside core team, situation is a little complicated but I am more determined. :)

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Maciej Izak
In reply to this post by Free Pascal - General mailing list
2018-05-21 10:12 GMT+02:00 Sven Barth via fpc-pascal <[hidden email]>:
That is at least what I would *expect* for Delphi as well. And no, I'm definitely not underestimating their ability to come up with strange syntaxes... Do I do prefer not to think about it too much to avoid nightmares :P

xD
 
I've decided to lift the restriction again in r39078. Happy now?

I can't be fully happy because I am not part of FPC core anymore but for sure I am more happy than before :)

--
Best regards,
Maciej Izak

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12345