Re: [fpc-pascal] A new fpc desirable feature
Il 17/07/2018 23:40, Tomas Hajny ha scritto: Indeed - please, everybody make sure to keep the discussion on this list on topic, this thread doesn't belong to this list. You are perfectly right that the discussions on this list should be kept on topic. But I don't agree that this thread is out of place. It only has deviated from the core of the matter, as suggested by my post. The purpose of my post was not to joke or to troll. My aim was to point out, by means of a paradoxical proposal, that too many discussions suggest to transform fpc into something completely different, a sort of hybrid thing, mixing up C++ features, Ada features, Java features and God knows what else. I have not yet seen the proposal to get rid of begin/end and replace it with indentation level, but it appears to be just a matter of time! In that case, however, it turned out that even the craziest idea such as the please keyword wasn't new, but already present in the INTERCAL language, and this led to some off-topic remarks. You cannot think of anything crazy without discovering that someone crazier than you has already implemented it! However it remains that Pascal is a very good language, whose clarity and self consistency require some small sacrifice. Too many programmers do not realize that saving a bit of typing may cost a lot in debugging and maintaining, and that what matters is not the time spent in typing, but the total time from the beginning, up to a fully debugged production ready program, which can be maintained by other people as well. Sorry for the extra noise generated, but the main point remains. Please help to keep this list on its topic, which is to help users to exploit Pascal at his best, to point bugs or things that can be improved, and not to betray Pascal spirit. Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
They observably *are* good though, now that they've been implemented, especially in combination with management operators. These are features that objectively make FPC better. I'm unsure what the original concern could have even possibly been, other than some vague notion of "well, records didn't have methods before, so they shouldn't now!". Classes are unsuitable performance-wise for many use cases, and TP objects lack important features such as variant parts. Advanced records are a great lightweight in-between point. On Tue, Jul 17, 2018 at 4:15 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Am 17.07.2018 um 20:00 schrieb Ryan Joseph: > >> >> On Jul 17, 2018, at 11:27 AM, Jim Lee wrote: >>> >>> Likewise, "modern" programming languages are all converging on a common >>> feature set, like cultural cross-pollination. >>> >> if that’s our mindset then how do we account for times when we’ve >> actually identified a common pattern that a language feature could address? >> I’m thinking of things like methods in records, for..in loops etc… that >> made it into the language and are widely adopted and enjoyed. >> > Those specific features you mention were added because of Delphi > compatibility not because someone thought they are good. Florian even > likened records with methods to a can of worms before they were implemented. > > Regards, > Sven > > ___ > 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
[fpc-pascal] How to translate Delphi Assembly MOV EAX,[EBP+4]
The following delphi code when compiled by FPC, raised these errors: Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1, Errors: 10, Warnings: 2 StrBuffer.pas(100,19) Error: Unknown identifier "EAX" StrBuffer.pas(100,23) Error: Assembler syntax error in operand StrBuffer.pas(100,24) Error: Unknown identifier "EBP" StrBuffer.pas(100,29) Error: Invalid constant expression StrBuffer.pas(100,29) Error: Invalid reference syntax StrBuffer.pas(100,29) Warning: No size specified and unable to determine the size of the operands, using DWORD as default StrBuffer.pas(207,19) Error: Unknown identifier "EAX" StrBuffer.pas(207,23) Error: Assembler syntax error in operand StrBuffer.pas(207,24) Error: Unknown identifier "EBP" StrBuffer.pas(207,29) Error: Invalid constant expression StrBuffer.pas(207,29) Error: Invalid reference syntax StrBuffer.pas(207,29) Warning: No size specified and unable to determine the size of the operands, using DWORD as default Can anyone help me? class procedure TStrBuffer.Error(const Msg: string; Data: Integer); function ReturnAddr: Pointer; asm MOV EAX,[EBP+4] end; begin raise EListError.CreateFmt(Msg, [Data])at ReturnAddr; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to translate Delphi Assembly MOV EAX,[EBP+4]
Dennis schrieb am Mi., 18. Juli 2018, 17:19:
> The following delphi code when compiled by FPC, raised these errors:
> Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
> Errors: 10, Warnings: 2
> StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
> StrBuffer.pas(100,23) Error: Assembler syntax error in operand
> StrBuffer.pas(100,24) Error: Unknown identifier "EBP"
> StrBuffer.pas(100,29) Error: Invalid constant expression
> StrBuffer.pas(100,29) Error: Invalid reference syntax
> StrBuffer.pas(100,29) Warning: No size specified and unable to determine
> the size of the operands, using DWORD as default
> StrBuffer.pas(207,19) Error: Unknown identifier "EAX"
> StrBuffer.pas(207,23) Error: Assembler syntax error in operand
> StrBuffer.pas(207,24) Error: Unknown identifier "EBP"
> StrBuffer.pas(207,29) Error: Invalid constant expression
> StrBuffer.pas(207,29) Error: Invalid reference syntax
> StrBuffer.pas(207,29) Warning: No size specified and unable to determine
> the size of the operands, using DWORD as default
>
> Can anyone help me?
>
> class procedure TStrBuffer.Error(const Msg: string; Data: Integer);
>
>function ReturnAddr: Pointer;
>asm
>MOV EAX,[EBP+4]
>end;
>
> begin
>raise EListError.CreateFmt(Msg, [Data])at ReturnAddr;
> end;
>
There are two ways to solve this.
The first one is an easy one, however the code still won't be platform
independent due to the assembly code. For this simply add "{$asmmode
intel}" at the top.
The second solution is cross platform and with correct checks also Delphi
compatible:
=== code begin ===
raise EListError.CreateFmt(Msg, [Data]) at
{$ifdef fpc}
get_caller_addr(get_frame),
get_caller_frame(get_frame)
{$else}
ReturnAddr
{$endif} ;
=== code end ===
Disable the ReturnAddr function also with "{$ifndef fpc}...{$endif}" and
you should be set.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to translate Delphi Assembly MOV EAX,[EBP+4]
Il 18/07/2018 17:19, Dennis ha scritto:
The following delphi code when compiled by FPC, raised these errors:
Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
Errors: 10, Warnings: 2
StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
StrBuffer.pas(100,23) Error: Assembler syntax error in operand
StrBuffer.pas(100,24) Error: Unknown identifier "EBP"
StrBuffer.pas(100,29) Error: Invalid constant expression
StrBuffer.pas(100,29) Error: Invalid reference syntax
StrBuffer.pas(100,29) Warning: No size specified and unable to
determine the size of the operands, using DWORD as default
StrBuffer.pas(207,19) Error: Unknown identifier "EAX"
StrBuffer.pas(207,23) Error: Assembler syntax error in operand
StrBuffer.pas(207,24) Error: Unknown identifier "EBP"
StrBuffer.pas(207,29) Error: Invalid constant expression
StrBuffer.pas(207,29) Error: Invalid reference syntax
StrBuffer.pas(207,29) Warning: No size specified and unable to
determine the size of the operands, using DWORD as default
Can anyone help me?
class procedure TStrBuffer.Error(const Msg: string; Data: Integer);
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP+4]
end;
begin
raise EListError.CreateFmt(Msg, [Data])at ReturnAddr;
end;
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
It looks like Intel asm syntax, while fpc defaults to AT&T assembler.
According the docs you should prepend a switch
{$ASMMODE intel)
to your asm section, or at the top of the unit.
Hope that it helps,
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] A new fpc desirable feature
> On Jul 18, 2018, at 5:08 AM, Giuliano Colla > wrote: > > I have not yet seen the proposal to get rid of begin/end and replace it with > indentation level, but it appears to be just a matter of time! I’ve never heard of a single proposal to change the fundamentals of Pascal, only to extend it. That’s a good thing. I can’t think of any crazy features in FPC off the top of my head. I’ve never used try..except in my own code. Is that crazy? Python forcing indent is crazy. Swift forcing initialization is crazy. C# forcing visibility keywords for each variable is crazy. All those things are *optional* in Pascal and that’s why I love Pascal. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
> On Jul 18, 2018, at 7:14 AM, Ben Grasset wrote: > > Classes are unsuitable performance-wise for many use cases, and TP objects > lack important features such as variant parts. Advanced records are a great > lightweight in-between point. Yes indeed. Not being able to allocate classes on the stack is a scandal for Pascal. I don’t know why the devs decided classes must be on the heap and anything other than that would violate some supposed design principle (Delphi??). Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to translate Delphi Assembly MOV EAX,[EBP+4]
Thanks.
So the following will give an address+frame of the calling routine ?
get_caller_addr(get_frame), get_caller_frame(get_frame)
Dennis
Sven Barth via fpc-pascal wrote:
Dennis mailto:de...@avidsoft.com.hk>> schrieb
am Mi., 18. Juli 2018, 17:19:
The following delphi code when compiled by FPC, raised these errors:
Compile Project, Target: lib\x86_64-win64\Project1.exe: Exit code 1,
Errors: 10, Warnings: 2
StrBuffer.pas(100,19) Error: Unknown identifier "EAX"
StrBuffer.pas(100,23) Error: Assembler syntax error in operand
StrBuffer.pas(100,24) Error: Unknown identifier "EBP"
StrBuffer.pas(100,29) Error: Invalid constant expression
StrBuffer.pas(100,29) Error: Invalid reference syntax
StrBuffer.pas(100,29) Warning: No size specified and unable to
determine
the size of the operands, using DWORD as default
StrBuffer.pas(207,19) Error: Unknown identifier "EAX"
StrBuffer.pas(207,23) Error: Assembler syntax error in operand
StrBuffer.pas(207,24) Error: Unknown identifier "EBP"
StrBuffer.pas(207,29) Error: Invalid constant expression
StrBuffer.pas(207,29) Error: Invalid reference syntax
StrBuffer.pas(207,29) Warning: No size specified and unable to
determine
the size of the operands, using DWORD as default
Can anyone help me?
class procedure TStrBuffer.Error(const Msg: string; Data: Integer);
function ReturnAddr: Pointer;
asm
MOV EAX,[EBP+4]
end;
begin
raise EListError.CreateFmt(Msg, [Data])at ReturnAddr;
end;
There are two ways to solve this.
The first one is an easy one, however the code still won't be platform
independent due to the assembly code. For this simply add "{$asmmode
intel}" at the top.
The second solution is cross platform and with correct checks also
Delphi compatible:
=== code begin ===
raise EListError.CreateFmt(Msg, [Data]) at
{$ifdef fpc}
get_caller_addr(get_frame),
get_caller_frame(get_frame)
{$else}
ReturnAddr
{$endif} ;
=== code end ===
Disable the ReturnAddr function also with "{$ifndef fpc}...{$endif}"
and you should be set.
Regards,
Sven
___
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] Syntax changes suggestions
> On Jul 17, 2018, at 2:41 PM, Sven Barth via fpc-pascal > wrote: > > There is a more important difference: the developers and the users. Only > because the latters think an idea is good or probable the former do not > necessarily need to agree. And don't forget that we, the developers work on > this in our free time and thus don't have any interest on spending time on > features that we don't believe in. that’s fair of course but what should be we do if we want to contribute? Remember I basically finished macros with parameters but what should I do now? The devs seemed to all really despise the idea but is there a formal channel I should use to petition for the idea or something? I heard from maybe5 people that said it was a stupid idea (fair enough) but what do the rest of the FPC users say? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to translate Delphi Assembly MOV EAX,[EBP+4]
Dennis schrieb am Mi., 18. Juli 2018, 19:01: > Thanks. > > So the following will give an address+frame of the calling routine ? > get_caller_addr(get_frame), get_caller_frame(get_frame) > As long as you pass it to the "raise ... at", yes. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Ryan Joseph schrieb am Mi., 18. Juli 2018, 19:15: > > > > On Jul 17, 2018, at 2:41 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > There is a more important difference: the developers and the users. Only > because the latters think an idea is good or probable the former do not > necessarily need to agree. And don't forget that we, the developers work on > this in our free time and thus don't have any interest on spending time on > features that we don't believe in. > > that’s fair of course but what should be we do if we want to contribute? > Remember I basically finished macros with parameters but what should I do > now? The devs seemed to all really despise the idea but is there a formal > channel I should use to petition for the idea or something? I heard from > maybe5 people that said it was a stupid idea (fair enough) but what do the > rest of the FPC users say? > The devs have brought up reasons against the feature and you not accepting or reasons against it is not a reason for us to accept your reasons for the feature. And even if the majority of the users would be for the feature it will always take someone to commit it and if none of the devs want your feature than it won't be integrated. This is not a democracy. And to give you a slightly different example: around a year ago or so I implemented a IfThen() intrinsic that works like the if-statement, but as an expression (like C's trinary ?: operator including not evaluating the branch not taken). The majority of the users seemed to like it, but reasons against it surfaced and so I reverted it again. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Ryan Joseph schrieb am Mi., 18. Juli 2018, 19:00: > > > > On Jul 18, 2018, at 7:14 AM, Ben Grasset wrote: > > > > Classes are unsuitable performance-wise for many use cases, and TP > objects lack important features such as variant parts. Advanced records are > a great lightweight in-between point. > > Yes indeed. Not being able to allocate classes on the stack is a scandal > for Pascal. I don’t know why the devs decided classes must be on the heap > and anything other than that would violate some supposed design principle > (Delphi??). > A point against stack based classes is that Object Pascal's object model is highly geared towards polymorphism (with things like virtual class methods and constructors that C++ does not support). You can't make use of this however if the class is instantiated on the stack. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Am 17.07.2018 um 12:07 schrieb Michael Van Canneyt: If of course you write routines of several hundreds of lines (or thousands), then you probably would need to have such a feature. But I would fire any programmer that writes such code anyway, since it indicates he cannot think structured. You should fire the whole compiler development team then ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal > wrote: > > And to give you a slightly different example: around a year ago or so I > implemented a IfThen() intrinsic that works like the if-statement, but as an > expression (like C's trinary ?: operator including not evaluating the branch > not taken). The majority of the users seemed to like it, but reasons against > it surfaced and so I reverted it again. > That’s pretty disheartening honestly. So there was a useful feature users could be leveraging but it was turned down because it didn’t fit into some paradigm or something like that. Sorry to hear that. Since I’ve been using FPC in 2003-2004 the language has never forced any of its new features on me and I can still program Pascal like I did when I started in the 90’s. Forcing me to use features is where my line is crossed but I struggle to understand why we’re withholding good ideas from users to this extent. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
> On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal > wrote: > > A point against stack based classes is that Object Pascal's object model is > highly geared towards polymorphism (with things like virtual class methods > and constructors that C++ does not support). You can't make use of this > however if the class is instantiated on the stack. Isn't that what Object does though? Something strange happened when FPC implemented classes because they didn’t unify the model between stack and heap. That was the obvious thing to do in my mind. I remember back when I was using Objects and doing like C++ where I used new to allocate on the heap then dereference using ^. to access members. When classes came around I thought, this is nice, no more new and ^. everywhere and easier to use. Fast forward to today and I want the option to go stack based back but the models have diverged so much it’s not possible anymore. Just now I wanted to use TFPGList and I wanted it on the stack because I didn’t want it to survive outside the function I was in. What do I do now? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph wrote: > > >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal >> wrote: >> >> And to give you a slightly different example: around a year ago or so I >> implemented a IfThen() intrinsic that works like the if-statement, but as an >> expression (like C's trinary ?: operator including not evaluating the branch >> not taken). The majority of the users seemed to like it, but reasons against >> it surfaced and so I reverted it again. >> > > That’s pretty disheartening honestly. So there was a useful feature users > could be leveraging but it was turned down because it didn’t fit into some > paradigm or something like that. Sorry to hear that. > > Since I’ve been using FPC in 2003-2004 the language has never forced any of > its new features on me and I can still program Pascal like I did when I > started in the 90’s. Forcing me to use features is where my line is crossed > but I struggle to understand why we’re withholding good ideas from users to > this extent. > You can make the function yourself. That you may have problems with typing are indicative that the language could use a more expressive type system, not that it was a good idea to create an intrinsic that could (potentially) ignore types. Cheers, R0b0t1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
> On Jul 18, 2018, at 1:46 PM, R0b0t1 wrote: > > You can make the function yourself. That you may have problems with > typing are indicative that the language could use a more expressive > type system, not that it was a good idea to create an intrinsic that > could (potentially) ignore types. I don’t remember what it did exactly. Like this maybe? n = (x != 0) ? 10 : 20; if x <> 0 then n := 10 else n := 20; n := IfThen(x <> 0, 10, 20); People are probably sick of doing that and wanted a more concise statement. I’ve even seen people do stuff like this because they’re fighting the language. if x <> 0 then n := 10 else n := 20; They probably wanted something like this: n := if x <> 0 then 10 else 20; Not too crazy in my opinion. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Ryan Joseph schrieb am Mi., 18. Juli 2018, 21:37: > > > > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > And to give you a slightly different example: around a year ago or so I > implemented a IfThen() intrinsic that works like the if-statement, but as > an expression (like C's trinary ?: operator including not evaluating the > branch not taken). The majority of the users seemed to like it, but reasons > against it surfaced and so I reverted it again. > > > > That’s pretty disheartening honestly. So there was a useful feature users > could be leveraging but it was turned down because it didn’t fit into some > paradigm or something like that. Sorry to hear that. > Due to it essentially being an overload of IfThen in the Math unit there was the possibility of confusion not to mention that it would be the only function like construct that would not evaluate all parameters. When I'm going to add it again I'm probably going the Oxygen route and use an if-expression enabled with a modeswitch 🤷♀️ Since I’ve been using FPC in 2003-2004 the language has never forced any of > its new features on me and I can still program Pascal like I did when I > started in the 90’s. Forcing me to use features is where my line is crossed > but I struggle to understand why we’re withholding good ideas from users to > this extent. > The problem with any language feature is this: even if I don't use it someone else will and I'll sooner or later have to read such code. So in that sense any language feature is forced upon everyone. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Ryan Joseph schrieb am Mi., 18. Juli 2018, 21:41: > > > > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > A point against stack based classes is that Object Pascal's object model > is highly geared towards polymorphism (with things like virtual class > methods and constructors that C++ does not support). You can't make use of > this however if the class is instantiated on the stack. > > Isn't that what Object does though? Something strange happened when FPC > implemented classes because they didn’t unify the model between stack and > heap. That was the obvious thing to do in my mind. > You have to keep in mind the history here. The "object" type is from Turbo Pascal times and back then it already showed its weaknesses. Then along came Delphi and Borland decided to introduce a brand new object model based on the "class" type which tackled the weak points of the "object" type and introduced some more polymorphism for the type. You can't utilize polymorphism with "object" instances in the stack either. > I remember back when I was using Objects and doing like C++ where I used > new to allocate on the heap then dereference using ^. to access members. > When classes came around I thought, this is nice, no more new and ^. > everywhere and easier to use. Fast forward to today and I want the option > to go stack based back but the models have diverged so much it’s not > possible anymore. > > Just now I wanted to use TFPGList and I wanted it on the stack because I > didn’t want it to survive outside the function I was in. What do I do now? > I really wonder why you keep thinking that you need them on the stack. I'm developing in Object Pascal (and this the "class" based model) for around 16 years or so and I never felt the need to put a class on the stack. I'm saying that while I also work with C++ at work for nearly 5 years and *do* use stack based structs and classes there. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
R0b0t1 schrieb am Mi., 18. Juli 2018, 21:46: > On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph > wrote: > > > > > >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > >> > >> And to give you a slightly different example: around a year ago or so I > implemented a IfThen() intrinsic that works like the if-statement, but as > an expression (like C's trinary ?: operator including not evaluating the > branch not taken). The majority of the users seemed to like it, but reasons > against it surfaced and so I reverted it again. > >> > > > > That’s pretty disheartening honestly. So there was a useful feature > users could be leveraging but it was turned down because it didn’t fit into > some paradigm or something like that. Sorry to hear that. > > > > Since I’ve been using FPC in 2003-2004 the language has never forced any > of its new features on me and I can still program Pascal like I did when I > started in the 90’s. Forcing me to use features is where my line is crossed > but I struggle to understand why we’re withholding good ideas from users to > this extent. > > > > You can make the function yourself. You can't, because the main point of the intrinsic was that the parameter that was in the branch not taken was not evaluated at all just like with the if-statement. Normal function calls will always evaluate the parameters. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wed, Jul 18, 2018 at 3:57 PM, Sven Barth via fpc-pascal wrote: > Ryan Joseph schrieb am Mi., 18. Juli 2018, > 21:37: >> >> >> >> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal >> > wrote: >> > >> > And to give you a slightly different example: around a year ago or so I >> > implemented a IfThen() intrinsic that works like the if-statement, but as >> > an >> > expression (like C's trinary ?: operator including not evaluating the >> > branch >> > not taken). The majority of the users seemed to like it, but reasons >> > against >> > it surfaced and so I reverted it again. >> > >> >> That’s pretty disheartening honestly. So there was a useful feature users >> could be leveraging but it was turned down because it didn’t fit into some >> paradigm or something like that. Sorry to hear that. > > > Due to it essentially being an overload of IfThen in the Math unit there was > the possibility of confusion not to mention that it would be the only > function like construct that would not evaluate all parameters. When I'm > going to add it again I'm probably going the Oxygen route and use an > if-expression enabled with a modeswitch 🤷♀️ > > >> Since I’ve been using FPC in 2003-2004 the language has never forced any >> of its new features on me and I can still program Pascal like I did when I >> started in the 90’s. Forcing me to use features is where my line is crossed >> but I struggle to understand why we’re withholding good ideas from users to >> this extent. > > > The problem with any language feature is this: even if I don't use it > someone else will and I'll sooner or later have to read such code. So in > that sense any language feature is forced upon everyone. > To go along with this, as it is all of the dialects of Pascal supported by FPC make for a difficult to understand language interface. Some of the "open" "standards" supported have very warty featuresets already. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wed, Jul 18, 2018 at 4:08 PM, Sven Barth via fpc-pascal wrote: > R0b0t1 schrieb am Mi., 18. Juli 2018, 21:46: >> >> On Wed, Jul 18, 2018 at 2:04 PM, Ryan Joseph >> wrote: >> > >> > >> >> On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal >> >> wrote: >> >> >> >> And to give you a slightly different example: around a year ago or so I >> >> implemented a IfThen() intrinsic that works like the if-statement, but as >> >> an >> >> expression (like C's trinary ?: operator including not evaluating the >> >> branch >> >> not taken). The majority of the users seemed to like it, but reasons >> >> against >> >> it surfaced and so I reverted it again. >> >> >> > >> > That’s pretty disheartening honestly. So there was a useful feature >> > users could be leveraging but it was turned down because it didn’t fit into >> > some paradigm or something like that. Sorry to hear that. >> > >> > Since I’ve been using FPC in 2003-2004 the language has never forced any >> > of its new features on me and I can still program Pascal like I did when I >> > started in the 90’s. Forcing me to use features is where my line is crossed >> > but I struggle to understand why we’re withholding good ideas from users to >> > this extent. >> > >> >> You can make the function yourself. > > > You can't, because the main point of the intrinsic was that the parameter > that was in the branch not taken was not evaluated at all just like with the > if-statement. Normal function calls will always evaluate the parameters. > I understand, but you can get close. That is why I mentioned type safety. Ignoring those things seems kind of anti-Pascal way. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
The "I might have to read code I don't like" argument people seem to keep resorting to comes off as rather childish, frankly. It's entirely subjective and specific to each person. For example, does *anyone *actually think the strange "lowercase everything" capitalization style the compiler uses is "readable" nowadays? It seems rather unlikely that's what would have ended up being used if FPC was started today. On Wed, Jul 18, 2018 at 4:57 PM, Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > Ryan Joseph schrieb am Mi., 18. Juli 2018, > 21:37: > >> >> >> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal < >> fpc-pascal@lists.freepascal.org> wrote: >> > >> > And to give you a slightly different example: around a year ago or so I >> implemented a IfThen() intrinsic that works like the if-statement, but as >> an expression (like C's trinary ?: operator including not evaluating the >> branch not taken). The majority of the users seemed to like it, but reasons >> against it surfaced and so I reverted it again. >> > >> >> That’s pretty disheartening honestly. So there was a useful feature users >> could be leveraging but it was turned down because it didn’t fit into some >> paradigm or something like that. Sorry to hear that. >> > > Due to it essentially being an overload of IfThen in the Math unit there > was the possibility of confusion not to mention that it would be the only > function like construct that would not evaluate all parameters. When I'm > going to add it again I'm probably going the Oxygen route and use an > if-expression enabled with a modeswitch 🤷♀️ > > > Since I’ve been using FPC in 2003-2004 the language has never forced any >> of its new features on me and I can still program Pascal like I did when I >> started in the 90’s. Forcing me to use features is where my line is crossed >> but I struggle to understand why we’re withholding good ideas from users to >> this extent. >> > > The problem with any language feature is this: even if I don't use it > someone else will and I'll sooner or later have to read such code. So in > that sense any language feature is forced upon everyone. > > Regards, > Sven > >> > ___ > 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] Syntax changes suggestions
Ironically, type safety is a good argument for the further development of various generics related things. Yet unfortunately I don't think anyone is going to stop using the Contnrs unit in new code anytime soon... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
Well, the array TFPGList uses for storage would still be allocated on the heap in any case no matter what... On Wed, Jul 18, 2018 at 3:10 PM, Ryan Joseph wrote: > > > > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > A point against stack based classes is that Object Pascal's object model > is highly geared towards polymorphism (with things like virtual class > methods and constructors that C++ does not support). You can't make use of > this however if the class is instantiated on the stack. > > Isn't that what Object does though? Something strange happened when FPC > implemented classes because they didn’t unify the model between stack and > heap. That was the obvious thing to do in my mind. > > I remember back when I was using Objects and doing like C++ where I used > new to allocate on the heap then dereference using ^. to access members. > When classes came around I thought, this is nice, no more new and ^. > everywhere and easier to use. Fast forward to today and I want the option > to go stack based back but the models have diverged so much it’s not > possible anymore. > > Just now I wanted to use TFPGList and I wanted it on the stack because I > didn’t want it to survive outside the function I was in. What do I do now? > > Regards, > Ryan Joseph > > ___ > 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] Syntax changes suggestions
> On Jul 18, 2018, at 3:05 PM, Sven Barth via fpc-pascal > wrote: > > You have to keep in mind the history here. The "object" type is from Turbo > Pascal times and back then it already showed its weaknesses. Then along came > Delphi and Borland decided to introduce a brand new object model based on the > "class" type which tackled the weak points of the "object" type and > introduced some more polymorphism for the type. > You can't utilize polymorphism with "object" instances in the stack either. I didn’t know object had polymorphism limitations. What are they exactly? > I really wonder why you keep thinking that you need them on the stack. I'm > developing in Object Pascal (and this the "class" based model) for around 16 > years or so and I never felt the need to put a class on the stack. I'm saying > that while I also work with C++ at work for nearly 5 years and *do* use stack > based structs and classes there. 1) For general efficiency of not allocating a block of memory on the heap when I know for absolute 100% certainty I don’t need it beyond the current stack frame. For high performance situations it really does matter since you start dealing with heap fragmentation and extra overhead with the memory manager. I was doing a game engine recently and doing the create/free thing when I knew I didn’t have to was painful. 2) Often when declaring a variable I know with absolute 100% certainty that it will not survive the stack frame and I’ll be calling Free at the end of the function. I’d like to just stop thinking about memory management at that point and be ensured the class will be freed at the end of the function. C++ calls the destructor for you but FPC doesn’t do this for some reason. Why? Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
> On Jul 18, 2018, at 4:01 PM, Ben Grasset wrote:
>
> Well, the array TFPGList uses for storage would still be allocated on the
> heap in any case no matter what…
That’s true but the other part remains true.
Here’s from the FPC compiler itself. sc is declared at the top and ~400 lines
later it’s freed. If they knew they were going to free at the end of the
function anyways why did they have to go all the way to bottom to do it? if you
want to make sure it’s freed you need to scroll through the entire 400 lines to
confirm this.
Personally for my taste I would like to just add a little keyword to the end of
the variable so I don’t have to worry about it later.
var
sc : TFPObjectList;
begin
old_block_type:=block_type;
block_type:=bt_var;
recst:=tabstractrecordsymtable(symtablestack.top);
{$if defined(powerpc) or defined(powerpc64)}
is_first_type:=true;
{$endif powerpc or powerpc64}
{ Force an expected ID error message }
if not (token in [_ID,_CASE,_END]) then
consume(_ID);
{ read vars }
sc:=TFPObjectList.create(false);
400 lines later….
{ free the list }
sc.free;
{$ifdef powerpc}
is_first_type := false;
{$endif powerpc}
block_type:=old_block_type;
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] Syntax changes suggestions
On Wed, 18 Jul 2018 14:33:51 -0600 Ryan Joseph wrote: > They probably wanted something like this: > > n := if x <> 0 then 10 else 20; > > Not too crazy in my opinion. Only if you think that changing a statement to an expression is not 'too crazy'. Btw in Kotlin if is an expression: val n = if (x != 0) 10 else 20 But in pascal it's not and it's IMHO no small change to make it one. R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wed, 18 Jul 2018 15:39:58 -0600 Ryan Joseph wrote: > 1) For high performance situations it really does matter... I was > doing a game engine recently and doing the create/free thing when I knew I > didn’t have to was painful. For high performance in a game engine you should not allocate/deallocate memory in the game loop at all (can be done, have done it*, so no arguing there). Increases the performance and frees you of doing "the create/free thing", that's killing two birds with one stone. Outside the game loop you do not need such a 'high performance' anymore. R. *The game uses procedural/random level generation and depending on skill there can be over 300 levels in a single run, with all allocation/deallocation happening before/after a run. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wed, 18 Jul 2018 16:12:41 -0600 Ryan Joseph wrote: > Personally for my taste I would like to just add a little keyword to the end > of the variable so I don’t have to worry about it later. 1) little, innocent deallocation feature A 2) other user comes along: "We already have A, can it be improved a little to work in situation X, too?" 3) n other users come along 4) "Pascal garbage collection - You have earned a trophy!" ;) R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
> For high performance in a game engine you should not allocate/deallocate memory in the game loop at all (can be done, have done it*, so no arguing there). This is a massive oversimplification. Many *modern* game engines do not even have the kind of loop you're thinking of. > Outside the game loop you do not need such a 'high performance' anymore. Says who? On Wed, Jul 18, 2018 at 9:08 PM, Reimar Grabowski wrote: > On Wed, 18 Jul 2018 15:39:58 -0600 > Ryan Joseph wrote: > > > 1) For high performance situations it really does matter... I was > doing a game engine recently and doing the create/free thing when I knew I > didn’t have to was painful. > > For high performance in a game engine you should not allocate/deallocate > memory in the game loop at all (can be done, have done it*, so no arguing > there). Increases the performance and frees you of doing "the create/free > thing", that's killing two birds with one stone. Outside the game loop you > do not need such a 'high performance' anymore. > > R. > > *The game uses procedural/random level generation and depending on skill > there can be over 300 levels in a single run, with all > allocation/deallocation happening before/after a run. > ___ > 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] Syntax changes suggestions
Yawn, more F.U.D. On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski wrote: > On Wed, 18 Jul 2018 16:12:41 -0600 > Ryan Joseph wrote: > > > Personally for my taste I would like to just add a little keyword to the > end of the variable so I don’t have to worry about it later. > > 1) little, innocent deallocation feature A > 2) other user comes along: "We already have A, can it be improved a little > to work in situation X, too?" > 3) n other users come along > 4) "Pascal garbage collection - You have earned a trophy!" ;) > > R. > ___ > 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] Syntax changes suggestions
Hello everybody, The discussion in this thread seems to be endless and arguments are repeating over and over. Moreover, some of the words and statements having appeared in certain posts are better avoided in polite communication. Everybody, please, think twice whether your post adds value (repetition of arguments and previously declined feature requests does not, attacks even less). Thank you Tomas (one of FPC mailing list moderators) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wed, 18 Jul 2018 21:26:05 -0400 Ben Grasset wrote: > This is a massive oversimplification. Many *modern* game engines do not > even have the kind of loop you're thinking of. Please tell me where I can read up about those engines without cyclic executive? Are those engines interrupt driven or how are they working? Where is the gain in not having a loop? Keeping your timing consistent with just semaphores sounds like a nightmare to me and not a win. In the end the loop is in the OS (listening for events/interrupts) no matter what you do (except using a real time OS, but I don't know any console running on one (they run BSD) and PC gaming is Windows). I am little out of the loop (no pun intended) regarding game engines so which engines are *modern*? Unreal 5 does still have a loop and current Unity, too, so they seem to be old fashioned (contrary to me thinking they are modern). >> Outside the game loop you do not need such a 'high performance' anymore. >Says who? Mr. Common-Sense says that you can waste a few nano/milliseconds if you are outside a run and only updating (slow) user input and interface (menus). But he's not always right and eager to hear about situations where this time cannot be spent. R. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Syntax changes suggestions
On Wednesday 18 July 2018 23:30:19 Ben Grasset wrote: > > For example, does *anyone *actually think the strange "lowercase > everything" capitalization style the compiler uses is "readable" nowadays? Yes. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
