Syntax changes suggestions

classic Classic list List threaded Threaded
113 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ryan Joseph


> On Jul 18, 2018, at 3:05 PM, Sven Barth via fpc-pascal <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ben Grasset
In reply to this post by Ryan Joseph
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 <[hidden email]> wrote:


> On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

Re: Syntax changes suggestions

Ryan Joseph


> On Jul 18, 2018, at 4:01 PM, Ben Grasset <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Reimar Grabowski
In reply to this post by Ryan Joseph
On Wed, 18 Jul 2018 14:33:51 -0600
Ryan Joseph <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Reimar Grabowski
In reply to this post by Ryan Joseph
On Wed, 18 Jul 2018 15:39:58 -0600
Ryan Joseph <[hidden email]> wrote:

> 1) For high performance situations it really does matter... <snip> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Reimar Grabowski
In reply to this post by Ryan Joseph
On Wed, 18 Jul 2018 16:12:41 -0600
Ryan Joseph <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ben Grasset
In reply to this post by Reimar Grabowski
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 <[hidden email]> wrote:
On Wed, 18 Jul 2018 15:39:58 -0600
Ryan Joseph <[hidden email]> wrote:

> 1) For high performance situations it really does matter... <snip> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

Re: Syntax changes suggestions

Ben Grasset
In reply to this post by Reimar Grabowski
Yawn, more F.U.D.

On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski <[hidden email]> wrote:
On Wed, 18 Jul 2018 16:12:41 -0600
Ryan Joseph <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

Re: Syntax changes suggestions

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

Re: Syntax changes suggestions

Reimar Grabowski
In reply to this post by Ben Grasset
On Wed, 18 Jul 2018 21:26:05 -0400
Ben Grasset <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Martin Schreiber-2
In reply to this post by Ben Grasset
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Mark Morgan Lloyd-5
In reply to this post by Ryan Joseph
On 18/07/18 20:45, Ryan Joseph wrote:

>> On Jul 18, 2018, at 1:46 PM, R0b0t1 <[hidden email]> 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 := 10else  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.

Without wanting to reopen the debate or appear to be criticising the
developers, ALGOL-60 did this:

FOR I := 1 STEP 6 UNTIL M DO
BEGIN  PCHTX(SYTB[I], WRITEBUFFER[0],
         IF M-I > 6 THEN 6 ELSE M-I+1);
     WRITE (PCH,10,WRITEBUFFER[*]);
     CLEAR(WRITEBUFFER[0],9)
END;

I make no apology for the layout, since that's a fragment of Wirth's own
code.

--
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: Syntax changes suggestions

Marco van de Voort
In reply to this post by Ryan Joseph

In our previous episode, Ryan Joseph said:
>
> 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.

No, because blind copying from one language to another is not always
feasible.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Bo Berglund
In reply to this post by Tomas Hajny-2
On Thu, 19 Jul 2018 03:42:26 +0200, "Tomas Hajny"
<[hidden email]> wrote:

>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)

+1

And please move this thread to the free-pascal.social group...


--
Bo Berglund
Developer in Sweden

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

Re: Syntax changes suggestions

Ben Grasset
In reply to this post by Martin Schreiber-2
I'm quite certain a lot of people would disagree with you on that. But there you have the reason why the "having to read code you don't like looking at" argument makes no sense. It's completely subjective. 

On Thu, Jul 19, 2018 at 12:37 AM, Martin Schreiber <[hidden email]> wrote:
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

Re: Syntax changes suggestions

Ben Grasset
In reply to this post by Marco van de Voort
If a feature works as intended and is useful (which is all that matters), how is it "blind copying"?

On Thu, Jul 19, 2018 at 7:25 AM, Marco van de Voort <[hidden email]> wrote:

In our previous episode, Ryan Joseph said:
>
> 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.

No, because blind copying from one language to another is not always
feasible.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


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

Re: Syntax changes suggestions

Free Pascal - General mailing list
Am 20.07.2018 um 00:53 schrieb Ben Grasset:
> If a feature works as intended and is useful (which is all that
> matters), how is it "blind copying"?
Because a feature might change the language in a way that's not in the
spirit of the language. Look at how Delphi implemented attributes:
they're declared in front of the types, fields, parameters, whatever,
simply copied from how C# implemented them while in the spirit of Pascal
they should have been *after* the declarations.

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: Syntax changes suggestions

Michael Van Canneyt


On Fri, 20 Jul 2018, Sven Barth via fpc-pascal wrote:

> Am 20.07.2018 um 00:53 schrieb Ben Grasset:
>> If a feature works as intended and is useful (which is all that
>> matters), how is it "blind copying"?
> Because a feature might change the language in a way that's not in the
> spirit of the language. Look at how Delphi implemented attributes:
> they're declared in front of the types, fields, parameters, whatever,
> simply copied from how C# implemented them while in the spirit of Pascal
> they should have been *after* the declarations.

There is more to a language than 'works as intended and is useful'.

If this were "all that matters", you must consequently switch to the language
with the most features (whatever it is these days). Many do so.

But there can be other criteria as well. For example readability.
I find the C family of languages with their abundance of brackets utterly unreadable.
Conciseness is also valued by many.
Scala for example is very concise, but because of this, utterly unreadable.
I often need to re-read a statement 3 times to understand what is happening.

This is not to say that Pascal should stay immutable, or that readability is
the only criterion.

There is definitely room for improvement in Pascal.
And improvements will be made, but adhering to the spirit of Pascal.
(intentionally left undefined)

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: Syntax changes suggestions

Marco van de Voort
In reply to this post by Ben Grasset
In our previous episode, Ben Grasset said:
> If a feature works as intended and is useful (which is all that matters),

The first is not sure, the second is extremely subjective.

The point is that border conditions can vary between source and destination
language. How features parse, how they interact with other features etc etc,
whether it is supportable long term.

> how is it "blind copying"?

Because such statements (as your first line above) are blind to those
considerations.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

R0b0t1
In reply to this post by Free Pascal - General mailing list
On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal
<[hidden email]> wrote:

> Am 20.07.2018 um 00:53 schrieb Ben Grasset:
>>
>> If a feature works as intended and is useful (which is all that matters),
>> how is it "blind copying"?
>
> Because a feature might change the language in a way that's not in the
> spirit of the language. Look at how Delphi implemented attributes: they're
> declared in front of the types, fields, parameters, whatever, simply copied
> from how C# implemented them while in the spirit of Pascal they should have
> been *after* the declarations.
>

This is what bothers me about some of the Delphi extensions that are
requested, but also some things that are already in FPC. And like
other people have said: now it's too late. It's there forever, or a
length of time that is just as good when talking about software.

It's not to say all of these things are bad - it's just I wish more
thought would have gone into them. Perhaps that would mean changing
the feature so much that it doesn't resemble what was originally
proposed.

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