Re: [fpc-pascal] Constants in generics
Am Di., 6. Nov. 2018, 08:44 hat Ryan Joseph
geschrieben:
> I implemented a first draft of constants (integers) in generics. My reason
> was specifically that I wanted a way to add methods to static arrays and
> generic records is the only way to accomplish this AFAIK.
>
> If I fix this up will it be considered as a patch? I wanted to present the
> idea first before I spent any more time. Here’s what I has so far (on
> GitHub).
>
>
> https://github.com/genericptr/freepascal/commit/ec518542b2da7d7f016702a82b2d05349a01a6fb
>
> {$mode objfpc}
> {$modeswitch advancedrecords}
>
> program generic_constants;
>
> type
> generic TList = record
> list: array[0..U-1] of T;
> function capacity: integer;
> end;
>
> function TList.capacity: integer;
> begin
> result := U;
> end;
>
> var
> nums: specialize TList;
> strs: specialize TList;
> begin
> writeln('sizeof:',sizeof(nums), ' capacity:',nums.capacity);
> writeln('sizeof:',sizeof(strs), ' capacity:',strs.capacity);
> end.
>
First of I'm not a fan of adding support for constants, mainly because it
will definitely not help parsing of inline specializations in mode Delphi
which are going to be annoying enough already.
That said: even if we do add it, then only if a generic constant parameter
is designated as such with "const N" in the generic declaration instead of
merely "N", so that the compiler does not assume it's a type.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
> On Nov 6, 2018, at 8:21 PM, Sven Barth via fpc-pascal > wrote: > > First of I'm not a fan of adding support for constants, mainly because it > will definitely not help parsing of inline specializations in mode Delphi > which are going to be annoying enough already. Can you give an example? There’s lots of ways generics can be used and I tested in only a few. This is a very important improvement because it allows us to extend static arrays in ways we haven’t been able to do before. Unless I missed something huge it seems like a simple thing to implement (see the minor changes I made in a single unit). > > That said: even if we do add it, then only if a generic constant parameter is > designated as such with "const N" in the generic declaration instead of > merely "N", so that the compiler does not assume it's a type. Why is this preferable? If you tried to pass a type for a constant in a specialization then you’d probably just get a type error which is easy to catch. Generics in FPC are already very verbose (“specialize" keyword is exhaustingly long) but adding “const” is at least a small cosmetic change in a single location. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Firebird vs. SQLite vs. PosgreSQL
Hi, This isn't a Free Pascal question but I wanted to ask about the Firebird database [1] because it seems as the Free Pascal community uses it the most by far, so I hope it isn't too off-topic. I've read the Firebird webpage and installed it but I can't seem to find documentation on how it compares to SQLite and PostgreSQL. My high level understanding is that it sits somewhere it between but I'm looking for more in depth comparisons on performance, data integrity tests and maybe even some real world experience anecdotes (+ive and -ive) on deployment, maintenance etc. Thanks! -deech [1] https://firebirdsql.org/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird vs. SQLite vs. PosgreSQL
Hi, Comparasion of some basic features between database engines you can find at: https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems L. > Hi, > This isn't a Free Pascal question but I wanted to ask about the > Firebird database [1] because it seems as the Free Pascal community > uses it the most by far, so I hope it isn't too off-topic. > > I've read the Firebird webpage and installed it but I can't seem to > find documentation on how it compares to SQLite and PostgreSQL. My > high level understanding is that it sits somewhere it between but I'm > looking for more in depth comparisons on performance, data integrity > tests and maybe even some real world experience anecdotes (+ive and > -ive) on deployment, maintenance etc. > > Thanks! > -deech > > [1] https://firebirdsql.org/ > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
Am Di., 6. Nov. 2018, 14:35 hat Ryan Joseph geschrieben: > > > > On Nov 6, 2018, at 8:21 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > First of I'm not a fan of adding support for constants, mainly because > it will definitely not help parsing of inline specializations in mode > Delphi which are going to be annoying enough already. > > Can you give an example? There’s lots of ways generics can be used and I > tested in only a few. > Complex inline specializations containing, for example a multiplication with specializations on the left and the right side are currently not possible in mode Delphi. In addition to that Delphi allows overloads of generic types with variables and constants, so when the parser encounters "Bla" it does not know whether it needs to start a specialization or an expression. This is already annoying enough to solve with merely types, but if the right side of the "<" can also take constants for generics that gets downright proplematic. > > > > That said: even if we do add it, then only if a generic constant > parameter is designated as such with "const N" in the generic declaration > instead of merely "N", so that the compiler does not assume it's a type. > > Why is this preferable? If you tried to pass a type for a constant in a > specialization then you’d probably just get a type error which is easy to > catch. Generics in FPC are already very verbose (“specialize" keyword is > exhaustingly long) but adding “const” is at least a small cosmetic change > in a single location. > Specialization is an expensive operation. When the compiler can already decide that "Something" can never be valid, because it's declared as "Something", then this is preferable. Otherwise the user might get some cryptic error message during the specialization, because "SomeOtherType" is used where only a constant can be used. Pascal is considered a type safe language and without forcing users to decorate such parameters as "const" you essentially allow users to mix types and constants. Not to mention that parsing the generic can already be done more correctly then it could be if the parameter is a typesym (which it would be right now). You can't do e.g. "const SomeOtherConst = ConstParam * Pi" that way as it would mean to ease up the compiler's restrictions for type checking even more. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Constants in generics
> On Nov 6, 2018, at 11:19 PM, Sven Barth via fpc-pascal > wrote: > > Complex inline specializations containing, for example a multiplication with > specializations on the left and the right side are currently not possible in > mode Delphi. In addition to that Delphi allows overloads of generic types > with variables and constants, so when the parser encounters "Bla not yet encountered the ">" it does not know whether it needs to start a > specialization or an expression. This is already annoying enough to solve > with merely types, but if the right side of the "<" can also take constants > for generics that gets downright proplematic. Can you show full a code example? If it really is so problematic because of something Delphi does then maybe it’s best left to objfpc mode until it can be resolved. > Specialization is an expensive operation. When the compiler can already > decide that "Something" can never be valid, because > it's declared as "Something", then this is preferable. Otherwise > the user might get some cryptic error message during the specialization, > because "SomeOtherType" is used where only a constant can be used. > Pascal is considered a type safe language and without forcing users to > decorate such parameters as "const" you essentially allow users to mix types > and constants. > Not to mention that parsing the generic can already be done more correctly > then it could be if the parameter is a typesym (which it would be right now). > You can't do e.g. "const SomeOtherConst = ConstParam * Pi" that way as it > would mean to ease up the compiler's restrictions for type checking even > more. I guess if you include const it could save some compile time if you tried to specialize with the wrong type? It’s a pretty minor savings but that’s ok. type generic TList = record list: array[0..U-1] of T; function capacity: integer; end; Btw I only implemented this with integers (no strings or floats) because afaik this feature is only useful for arrays. I guess you could use non-ints for default parameters but this is probably a stupid idea because of how much compile time you’ll add to specialize a large amount of types. Is there any reason to support strings and floats? type generic TCaller = record procedure Say(message:T = U); end; var caller: specialize TCaller; begin caller.Say; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Dynamic array bug
I finally built the trunk today (version 3.3.1) to try new dynamic array
features and a bug fix Sven did a while ago but I’m still getting errors.
Did I get the wrong version or something? I thought these things were working
now.
{$mode objfpc}
{$modeswitch advancedrecords}
program general;
type
TIntArray = array of integer;
TMyRec = record
a: TIntArray;
class operator := (right:TIntArray):TMyRec;
end;
class operator TMyRec.:= (right:TIntArray):TMyRec;
begin
result.a := right;
end;
var
r: TMyRec;
a: TIntArray;
begin
r := [1, 2, 3]; // Incompatible types: got "Set Of Byte" expected
"TMyRec"
a := [1, 2, 3];
a := a + [4]; // Operator is not overloaded: "{Dynamic} Array Of
LongInt" + "Set Of Byte"
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] Dynamic array bug
Hi Ryan. On Wed, Nov 7, 2018 at 1:13 AM Ryan Joseph wrote: > I finally built the trunk today (version 3.3.1) to try new dynamic array > features and a bug fix Sven did a while ago but I’m still getting errors. > > Did I get the wrong version or something? I thought these things were > working now. Same problem here: Error: Incompatible types: got "Set Of Byte" expected "TMyRec" Error: Operator is not overloaded: "TIntArray" + "Set Of Byte" It seems a bug, because the same code works fine on Delphi by changing operator from ":=" to its respective name "Implicit". My compiler ver: FPC 3.3.1 [2018/11/07] for x86_64 (Linux) -- Silvio Clécio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Dynamic array bug
> On Nov 7, 2018, at 12:57 PM, silvioprog wrote: > > It seems a bug, because the same code works fine on Delphi by changing > operator from ":=" to its respective name "Implicit”. Good to know. I reported this before and Sven said it was fixed in an update (after another user had submitted the original patch). Are you able to get a := a + [4]; to work? I’m looking Sven’s old message titled "Feature announcement: Dynamic array extensions” and he says + operator now works. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
