Re: [fpc-pascal] Feature announcement: implicit generic function specializations
> On Apr 23, 2022, at 9:09 PM, Hairy Pixels wrote: > > 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. I was thinking about this more and I actually feel like we got this backwards in Pascal and the default should be implicit specialization with manual specialization being a fallback for more challenging cases. If you have a function: generic function Add(left, right: T): T; And the programmer intends to call it like: Add(1,1); or var a, b: Integer; begin Add(a, b); Why should the programmer need to tell the compiler it’s dealing with Integer when it’s so obvious from the types being used? All the programmer should know is that there is type “T” and any type will work (I know, we don’t have type constraints for built-in types and yes, we should implement that). For the case of types I understand we must specialize because we’re creating a new type each time and there is nothing to infer from the context, but for functions it’s backwards, that is we know the types being used, we just need to choose the right function based on those types. If it’s ever allowed to do generic type helpers (I would like do this also) I think the same idea applies. Manually specializing the type doesn’t provide any better control then allowing the compiler to specialize based on the type being extended. type generic TArrayHelper = type helper for array of T procedure Add(value: T); end; var a: array of integer; begin a.Add(1); // specialize TArrayHelper since the compiler clearly knows the type used is Integer. end. 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
Op 24/04/2022 om 04:37 schreef Hairy Pixels via fpc-pascal: 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? It's a ISO pascal feature that is a kind of open array construct where you can pass non zero based arrays too. The limitation that dynamic/open arrays are always zero based is a Delphi simplification. It is more or less meant that if to judge the non zero array bounderies features, you need to know the whole story. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] What's wrong with Leave?
On 24/04/2022 15:30, Виктор Матузенко via fpc-pascal wrote:
The test program:
begin
{$IF Declared(Leave)} Leave; {$ENDIF}
end.
"Leave" is declared as an intrinsic in the system unit because in MacPas
mode it means the same as "break" in UCSD-derivates.
We don't have support in the compiler for declaring intrinsics in units
other than the system unit (so we can't declare it in the macpas unit
instead), and we don't have a different system unit for each supported
syntax mode either (otherwise it would not be possible to mix units
compiled in different syntax modes in a single program), which is why
you see this behaviour.
Jonsa
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] What's wrong with Leave?
The test program:
begin
{$IF Declared(Leave)} Leave; {$ENDIF}
end.
The compilation error:
D:\data\temp>fpc -Mfpc leave_example.pas
Free Pascal Compiler
version 3.2.1 [2021/02/01] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling leave_example.pas
leave_example.pas(2,30) Error: Identifier not found "Leave"
leave_example.pas(4) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: D:\prog\FPC\fixes_3_2\bin\i386-Win32\ppc386.exe returned an
error exitcode
What's happening?
--
Victor Matuzenko (Виктор Матузенко)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Possible fpdebug issue
Lazarus 2.2 or 2.3 ? In 2.3 some work has been started to debug into dll... Is there a way to reproduce this? Also try: lazarus.exe --debug-log=c:\logfile.txt --debug-enable=DBG_EVENTS,DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS,DBG_VERBOSE_BRKPOINT,DBG_STATE,DBG_COMMAND_ECHO,DBG_DATA_MONITORS,DBG_LOCATION_INFO,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_THREADS,FPDBG_QUEUE,FPDEBUG_THREAD_CHECK,FPDBG_WINDOWS I am away for some days, so replies may take some time. On 24/04/2022 02:15, Thomas Kurz via fpc-pascal wrote: 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
