Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> On Apr 23, 2022, at 10:30 PM, Marco van de Voort via fpc-pascal > wrote: > > Btw since you are afaik an Apple user, did you actually use conformant > arrays, or do you base this on UCSD/Borland dialects only? I started with THINK Pascal on classic Mac OS but I never heard of conformant arrays. What are they? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Possible fpdebug issue
Dear all, I'm not sure whether or not this is an issue with fpdebug, so I'd like to describe it here first: I have a main program (Win32 GUI running on Win 8.1) which loads and unloads a DLL dynamically. I know that fpdebug is currently not able to debug DLLs, but imho I don't do so, but the issue might be related. The program runs fine when being run without debugger or when using GDB. However, a crash occurs when fpdebug is active and the call to "FreeLibrary" is made. The error is: Project raised exception class 'External: Unknown exception code $E0465043'. At address 76EB56E8. The DLL is my own and I tried to debug the Finalization section with GDB, but I cannot find an issue there. So imho unloading the DLL should not cause any trouble. As I said, I'm not trying to actually step into the DLL; I'm only using fpdebug in the main program and trying to step over the "FreeLibrary" line. Kind regards, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
On 23-4-2022 16:09, Hairy Pixels via fpc-pascal wrote: For 2) I'm also of the opinion of the others: this is unneeded syntactic sugar. There is already a way to declare arrays with a specific size and for a language it's in nearly all cases not good to provide multiple ways to achieve the same. Getting off topic but personally I think the idea of a range bound for arrays has been proven to be a bad idea from the original Pascal spec. Originally when learning pascal I think I did 1 indexed arrays but eventually realized it’s non-standard across other languages and doesn’t really provide any use. In 99.99% of cases I always do 0…n so it’s just wasting time at this point. In fact I would be really hard pressed to think of a time I did something besides 0…n… 0..n-1 I might hope. Btw since you are afaik an Apple user, did you actually use conformant arrays, or do you base this on UCSD/Borland dialects only? As I've written elsewhere: implicit function specializations as a feature might not have happened if Delphi did not support them as well, cause like 2) they are essentially syntactic sugar as well. The two languages I use commonly these days are Swift and C#, both of which do implicit function specialization by default. After you use a generic function a couple times it becomes apparent the compiler could infer the types and it’s less code to write so it’s natural that any language that has generic functions would support this feature. IMHO It is like with all shorthands, if an addition causes pitfalls, debugging those is usually worse then they ever save. I've no idea about how that is with this feature (and then most notably the integration in the Pascal language, since pitfalls are often due to combinations of features) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
Thank you for continuously enhancing Free Pascal. Happy to see every new
feature :)
Is there any work ongoing about overloaded properties? E.g.
property x: integer read GetX;
property x[aindex: integer]: integer write SetX;
I know that declaring the property only once and overloading the getters and
setters work, but sometimes I wish to have different read/readwrite/write
access for overloaded properties and this is not possible at the moment.
Furthermore, code completion in Lazarus doesn't show the different parameters
of overloaded properties.
- Original Message -
From: Sven Barth via fpc-pascal
To: fpc-annou...@lists.freepascal.org
Sent: Wednesday, April 20, 2022, 19:15:15
Subject: [fpc-pascal] Feature announcement: implicit generic function
specializations
Dear FPC community,
The FPC developers are pleased to announce the implementation of a new
feature: implicit generic function specializations. This feature was
implemented by Ryan Joseph, so thank you very much, Ryan.
This feature allows you to use generic routines (functions, procedures,
methods) without explicitely specializing them (“<…>” in Delphi modes
and “specialize …<…>” in non-Delphi modes) as long as the compiler can
determine the correct parameter types for the generic.
This feature is enabled with the modeswitch
ImplicitFunctionSpecialization and is for now not enabled by default as
this has the potential to break existing code.
Assume you have the following function:
=== code begin ===
generic function Add(aArg1, aArg2: T): T;
begin
Result := aArg1 + aArg2;
end;
=== code end ===
Up to now you could only use this function as follows:
=== code begin ===
SomeStr := specialize Add('Hello', 'World');
SomeInt := specialize Add(2, 5);
=== code end ===
However with implicit function specializations enabled you can also use
it as follows:
=== code begin ===
SomeStr := Add('Hello', 'World');
SomeInt := Add(2, 5);
=== code end ===
The compiler will automatically determine the type of the generic
parameters based on the parameters you pass in (this is always done left
to right). Depending on the passed in parameters (especially if you're
using constant values like in the example instead of variables) the
compiler might however pick a different type than you expected. You can
enforce a specific type by either explicitely specializing the method as
before or by inserting a type cast. In the example above the compile
will specialize the call with the parameters “2, 5” using an 8-bit
signed type (Pascal prefers signed types) instead of a LongInt as in the
explicit specialization. If you use “LongInt(2), 5” as parameters then
the compiler will pick that instead, however with “2, LongInt(5)” it
will still pick an 8-bit type, because the parameter types are
determined left to right.
If there exists a non-generic overload for which the parameters types
match exactly, the compiler will pick that instead of specializing
something anew. So assume you also have the following function in scope:
=== code begin ===
function Add(aArg1, aArg2: LongInt): LongInt;
begin
Result := aArg1 + aArg2;
end;
=== code end ===
In the case of “Add(2, 5)” the compiler will *not* pick the non-generic
function, because it determines that an 8-bit type is enough, however if
you use “Add(LongInt(2), 5)” the compiler will pick the non-generic
function.
Aside from simple parameters the compiler also supports arrays and
function/method variables:
=== code begin ===
generic function ArrayFunc(aArg: specialize TArray): T;
var
e: T;
begin
Result := Default(T);
for e in aArg do
Result := Result + e;
end;
type
generic TTest = function(aArg: T): T;
generic function Apply(aFunc: specialize TTest; aArg: T): T;
begin
Result := aFunc(aArg);
end;
function StrFunc(aArg: String): String;
begin
Result := UpCase(aArg);
end;
function NegFunc(aArg: LongInt): LongInt;
begin
Result := - aArg;
end;
begin
Writeln(ArrayFunc([1, 2, 3])); // will write 6
Writeln(ArrayFunc(['Hello', 'FPC', 'World'])); // will write
HelloFPCWorld
Writeln(Apply(@StrFunc, 'Foobar')); // will write FOOBAR
Writeln(Apply(@NegFunc, 42)); // will write -42
end.
=== code end ===
There are of course a few restrictions for this feature:
- all generic parameters must be used in the declaration of the routine
(implementation only type parameters are not allowed)
- all parameters that have a generic type must not be default
parameters, they need to be used in the call or their type must have
been fixed by a parameter further left (as currently default values for
parameters of a generic type are not supported this is not much of a
restriction, but should that change (e.g. Default(T)) then this
restriction will apply)
- the generic routine must not have constant generic parameters (this
might be extended in the future with e.g. static arrays or file types,
but for now this restriction stands)
- the result type
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> On Apr 23, 2022, at 3:40 PM, Sven Barth via fpc-pascal > wrote: > > For 2) I'm also of the opinion of the others: this is unneeded syntactic > sugar. There is already a way to declare arrays with a specific size and for > a language it's in nearly all cases not good to provide multiple ways to > achieve the same. Getting off topic but personally I think the idea of a range bound for arrays has been proven to be a bad idea from the original Pascal spec. Originally when learning pascal I think I did 1 indexed arrays but eventually realized it’s non-standard across other languages and doesn’t really provide any use. In 99.99% of cases I always do 0…n so it’s just wasting time at this point. In fact I would be really hard pressed to think of a time I did something besides 0…n… > > As I've written elsewhere: implicit function specializations as a feature > might not have happened if Delphi did not support them as well, cause like 2) > they are essentially syntactic sugar as well. The two languages I use commonly these days are Swift and C#, both of which do implicit function specialization by default. After you use a generic function a couple times it becomes apparent the compiler could infer the types and it’s less code to write so it’s natural that any language that has generic functions would support this feature. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
Am 22.04.2022 um 23:08 schrieb Rainer Stratmann via fpc-pascal:
Am Freitag, 22. April 2022, 19:53:34 CEST schrieben Sie:
Am 22.04.2022 um 15:48 schrieb Rainer Stratmann via fpc-pascal:
Am Mittwoch, 20. April 2022, 19:15:15 CEST schrieb Sven Barth via fpc-
pascal:
We don't deal in percentages, however it reduces the amount of typing
required to write code with a lot of specializations (in theory an IDE
like Lazarus *could* help here as well however).
Of course 'you' do. When I asked for a simple feature years ago it was
refused. And there were several explanations why this feature is not
necessary.
I quickly checked the archives and found two suggestions by you:
1) "Name of a var" from 2011 (
https://lists.freepascal.org/pipermail/fpc-pascal/2011-November/031256.html
)
2) "Declaration of arrays" from 2013 (
https://lists.freepascal.org/pipermail/fpc-pascal/2013-June/038496.html )
For 1) I'm still of the opinion that it would be useful especially
considering that we now have {$I %CURRENTROUTINE%} as well.
For 2) I'm also of the opinion of the others: this is unneeded syntactic
sugar. There is already a way to declare arrays with a specific size and
for a language it's in nearly all cases not good to provide multiple
ways to achieve the same.
As I've written elsewhere: implicit function specializations as a
feature might not have happened if Delphi did not support them as well,
cause like 2) they are essentially syntactic sugar as well.
Though contrary to your idea they don't provide an alternative way to
specialize functions, but really provide a way to explicitely declare
less. It's a real subtle difference between the two situations, but it's
there.
The main argument however is Delphi compatibility. The amount of users
that want features from Delphi is much higher than the amount of users
that require features from MikroPascal and thus features that are
syntactic sugar will see the light of day much easier.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Feature announcement: implicit generic function specializations
Am 23.04.2022 um 00:42 schrieb Martin Frb via fpc-pascal: Possible one more / Though more of an optimization. If the code has multiple Add(Int64(0), Int64(0)); then they will all use the same procedure (just break in the debugger and check the CRC). But if one specialization is explicit and the other implicit then 2 identical (as far as I can tell with -al ) functions (with diff CRC) are created. I would need to check why it generates two then. Please report this as well. There is however a subtle difference in the generate asm. The explicit specialization has comment for the source code # [6] begin ... # [7] Result := aArg1 + aArg2; ... The implicit does not have those. Actually I checked that a bit deeper. The comment occur in (and only in) the first specialization (implicit or explicit). All other specialization are without comments for the source. I had that issue in a different context already and it's related to the assembler writer and when it decides a line should be written again (cause at the basic level it would write the line comment for each instruction of that line and thus it needs to be reset correctly, but across functions that should be reset completely of course). I already have a fix for that, but as it's buried in a different branch it will be a little while longer. ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
