Re: [fpc-pascal] Syntax changes suggestions

[R0b0t1]

Well, I am also of the opinion that threadvar is kind of a kludge too.
I think part of the aesthetic of Pascal is that it reads fairly close
to English. Creating a lot of new compound words is a bit jarring.

As I just now figured out how to articulate the above, I have what I
think is a more consistent group of proposals. It will prevent needing
to create a lot of special keywords:

var
  c: thread TMyClass;
  d: auto TMyClass;


Or, perhaps even better:

thread var
  c: TMyClass;

managed var
  d: TMyClass;

Cheers,
 R0b0t1


On Thu, Jul 26, 2018 at 10:19 PM, Ryan Joseph
 wrote:
>
>
>> On Jul 25, 2018, at 8:05 AM, R0b0t1  wrote:
>>
>> This looks ugly. It also introduces modifiers to variable
>> declarations. Some features should not be part of the language, they
>> should be built on top of it.
>
>
> Yeah, introducing modifiers to variables is not so great. You could avoid 
> introducing modifiers but using a new section like “scopevar” which is 
> similar to “threadvar” I guess.
>
> scopevar
>   c: TMyClass;
> begin
>   c := TMyClass.Create;
>
> I accomplish this in my code using an auto release pool which empties at the 
> end of every event loop.
>
> var
>   c: TMyClass;
> begin
>   c := TMyClass.Create;
>   c.AutoRelease;
>
> // or
>   c := TMyClass.Instance; // calls Create + AutoRelease in the constructor
>
> That’s not so pretty either, involves extra constructors sometimes (if you 
> want to keep things pretty) and it requires extra infrastructure you need to 
> setup. Jonas told me once this is actually more efficient though since it 
> frees multiple objects all at the same time so it decreases heap 
> fragmentation (I think he meant). This idea is heavily utilized in all of 
> Apple’s Cocoa frameworks so it’s a sound solution.
>
>
> Meh, no free lunch, just food for thought. :)
>
> 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

[Ryan Joseph]

> On Jul 25, 2018, at 8:05 AM, R0b0t1  wrote:
> 
> This looks ugly. It also introduces modifiers to variable
> declarations. Some features should not be part of the language, they
> should be built on top of it.


Yeah, introducing modifiers to variables is not so great. You could avoid 
introducing modifiers but using a new section like “scopevar” which is similar 
to “threadvar” I guess.

scopevar
  c: TMyClass;
begin
  c := TMyClass.Create;

I accomplish this in my code using an auto release pool which empties at the 
end of every event loop.

var
  c: TMyClass;
begin
  c := TMyClass.Create;
  c.AutoRelease;

// or
  c := TMyClass.Instance; // calls Create + AutoRelease in the constructor

That’s not so pretty either, involves extra constructors sometimes (if you want 
to keep things pretty) and it requires extra infrastructure you need to setup. 
Jonas told me once this is actually more efficient though since it frees 
multiple objects all at the same time so it decreases heap fragmentation (I 
think he meant). This idea is heavily utilized in all of Apple’s Cocoa 
frameworks so it’s a sound solution.


Meh, no free lunch, just food for thought. :)

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

[Ben Grasset]

How is auto more "ugly" than literally any other modifier in the entire
language? They're all just english words, of varying length. Also building
features on top of a language will always result in worse performance than
having them be a part of it.

On Wed, Jul 25, 2018 at 10:05 AM, R0b0t1  wrote:

> On Mon, Jul 23, 2018 at 11:11 AM, Ryan Joseph
>  wrote:
> >
> >
> >> On Jul 22, 2018, at 4:54 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >>
> >> And that's why there are people who *do* care about it. Of course you
> can put everything and the kitchen think into a language. But if it doesn't
> fit the language than you'll simply end up with a melting pot that doesn't
> feel coherent. Also while people might not consciously think about the
> spirit of the language I think they'll feel if the language is coherent
> with itself or not.
> >
> > The spirit of the language is really hard to define in my opinion. I
> think we all agree that if we changed begin/end to {} we would all be
> offended but why again is “auto” not in the spirit of the language? It
> looks like Pascal to me. Calling Free at the end of blocks and inside
> destructors feels like Pascal to me.
> >
> > Telling the compiler to call it for me by typing “auto” instead of
> “Free” doesn’t feel non-pascal. I don’t get it.
> >
> > type
> > TMyClass = class
> > private
> > list: TFPGList; auto;
> > otherList: TFPGList; auto;
> > end;
> >
> > var
> > c: TMyClass; auto;
> >
> > begin
> > c := TMyClass.Create;
> >
>
> This looks ugly. It also introduces modifiers to variable
> declarations. Some features should not be part of the language, they
> should be built on top of it.
> ___
> 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

[Sven Barth via fpc-pascal]

R0b0t1  schrieb am Do., 26. Juli 2018, 09:53:

> On Mon, Jul 23, 2018 at 11:11 AM, Ryan Joseph
>  wrote:
> >
> >
> >> On Jul 22, 2018, at 4:54 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >>
> >> And that's why there are people who *do* care about it. Of course you
> can put everything and the kitchen think into a language. But if it doesn't
> fit the language than you'll simply end up with a melting pot that doesn't
> feel coherent. Also while people might not consciously think about the
> spirit of the language I think they'll feel if the language is coherent
> with itself or not.
> >
> > The spirit of the language is really hard to define in my opinion. I
> think we all agree that if we changed begin/end to {} we would all be
> offended but why again is “auto” not in the spirit of the language? It
> looks like Pascal to me. Calling Free at the end of blocks and inside
> destructors feels like Pascal to me.
> >
> > Telling the compiler to call it for me by typing “auto” instead of
> “Free” doesn’t feel non-pascal. I don’t get it.
> >
> > type
> > TMyClass = class
> > private
> > list: TFPGList; auto;
> > otherList: TFPGList; auto;
> > end;
> >
> > var
> > c: TMyClass; auto;
> >
> > begin
> > c := TMyClass.Create;
> >
>
> This looks ugly. It also introduces modifiers to variable
> declarations. Some features should not be part of the language, they
> should be built on top of it.
>

While I don't support the "auto" idea, you are also wrong in saying that it
"introduces" modifiers to variable declarations: there already are
modifiers like "cvar", "public" and "external".

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]

On Mon, Jul 23, 2018 at 11:11 AM, Ryan Joseph
 wrote:
>
>
>> On Jul 22, 2018, at 4:54 AM, Sven Barth via fpc-pascal 
>>  wrote:
>>
>> And that's why there are people who *do* care about it. Of course you can 
>> put everything and the kitchen think into a language. But if it doesn't fit 
>> the language than you'll simply end up with a melting pot that doesn't feel 
>> coherent. Also while people might not consciously think about the spirit of 
>> the language I think they'll feel if the language is coherent with itself or 
>> not.
>
> The spirit of the language is really hard to define in my opinion. I think we 
> all agree that if we changed begin/end to {} we would all be offended but why 
> again is “auto” not in the spirit of the language? It looks like Pascal to 
> me. Calling Free at the end of blocks and inside destructors feels like 
> Pascal to me.
>
> Telling the compiler to call it for me by typing “auto” instead of “Free” 
> doesn’t feel non-pascal. I don’t get it.
>
> type
> TMyClass = class
> private
> list: TFPGList; auto;
> otherList: TFPGList; auto;
> end;
>
> var
> c: TMyClass; auto;
>
> begin
> c := TMyClass.Create;
>

This looks ugly. It also introduces modifiers to variable
declarations. Some features should not be part of the language, they
should be built on top of it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Giuliano Colla]

Il 23/07/2018 18:11, Ryan Joseph ha scritto:


The spirit of the language is really hard to define in my opinion.


To the contrary, in an Open Source project, it is the easiest thing to 
define.
It is what the core developers deem to be the spirit of the language. 
That's all.


One should never forget what Open Source is: one or more persons, 
because of their personal motivations (fun, technical interest, 
altruism, egoistic desire to appear, whatever) decide to develop some 
software in their free time, without getting any money for that, and to 
share it with whomever is interested.


One should understand that it is *their* toy, not *our* toy.

We may suggest them to include new features, to modify existing ones, 
but to accept or to reject them it is just their choice. You cannot 
force them neither to spend their free time developing something they 
don't like, nor to accept a patch which in their judgement would taint 
their toy. It's as simple as that.


Open Source however provides an easy way out. If they don't like it, but 
you do need it or just want it, you are free to implement whatever you 
like on top of the existing project. Then you may just keep it for your 
personal usage, or share it, giving rise to another OS project. That's 
what Maciej Izak has done with its NewPascal.


If you don't know how to implement it, then you're in a worse situation, 
because you cannot judge the implications of what you request, which 
might require an effort not proportionate to the result, might conflict 
with a lot of other things, etc. etc. You have no other choice than to 
rely on core developers' judgement.


For those reasons I believe that this thread has become too long, and 
that it would be reasonable to end it.


Just my 2 cents.

Giuliano

--
Do not do unto 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

[Ryan Joseph]

> On Jul 22, 2018, at 4:54 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> And that's why there are people who *do* care about it. Of course you can put 
> everything and the kitchen think into a language. But if it doesn't fit the 
> language than you'll simply end up with a melting pot that doesn't feel 
> coherent. Also while people might not consciously think about the spirit of 
> the language I think they'll feel if the language is coherent with itself or 
> not.

The spirit of the language is really hard to define in my opinion. I think we 
all agree that if we changed begin/end to {} we would all be offended but why 
again is “auto” not in the spirit of the language? It looks like Pascal to me. 
Calling Free at the end of blocks and inside destructors feels like Pascal to 
me. 

Telling the compiler to call it for me by typing “auto” instead of “Free” 
doesn’t feel non-pascal. I don’t get it.

type
TMyClass = class
private
list: TFPGList; auto;
otherList: TFPGList; auto;  
end;

var
c: TMyClass; auto;

begin
c := TMyClass.Create;


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

[Santiago A.]

El 21/07/18 a las 22:43, Ben Grasset escribió:


Shouldn't the attribute tags just be put wherever it's easiest for the 
compiler to deal with them?

No, of course the shouldn't.
They should be put put where it is easier for programmer, or more 
readable, or coherence, or common sense, or other reasons.
How difficult is to implement for the compiler is a limit if our skills 
or state of art of compilers imposes, not a feature.



Saludos
Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 21.07.2018 um 22:43 schrieb Ben Grasset:
On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal 
> wrote:


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  - fpc-pascal@lists.freepascal.org

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




C# itself is heavily inspired by Delphi though, as it's another Anders 
Hejlsberg project. I fail to see what the "spirit of the language" has 
to do with anything as far as attributes, either.


Shouldn't the attribute tags just be put wherever it's easiest for the 
compiler to deal with them?
If we go by that then the current attribute syntax is especially bad, 
because the compiler now needs to gracefully fail with declarations like 
this:


=== code begin ===

[TSomeAttribute]
uses
  foobar;

=== code end ===

If there'd be a syntax to add them as postfix ones then it would be 
easier for the compiler (the following is merely an example):


=== code begin ===

type
  TSomeClass = class(TObject) with [TSomeAttribute]
    fSomeField with [TSomeOtherAttribute]: LongInt;
    property WhatEver: LongInt read fSomeField with [TYetAnotherAttribute];
  end;

=== code end ===



I think the vast majority of people care far more about 
how/usefulPascal actually is in real life/than they do
about whether or not it fulfills some not-well-defined notion of 
"spirit".
And that's why there are people who *do* care about it. Of course you 
can put everything and the kitchen think into a language. But if it 
doesn't fit the language than you'll simply end up with a melting pot 
that doesn't feel coherent. Also while people might not consciously 
think about the spirit of the language I think they'll feel if the 
language is coherent with itself or not.




Also, as far as I can tell, most of the people who use FPC would 
consider the Delphi way to be the correct or normal way of doing 
things in the first place.
Considering that more often than not there are discussions on these 
lists if we should continue to follow Delphi compatibility or not you 
might be surprised...


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

[Michael Van Canneyt]

On Sat, 21 Jul 2018, Ben Grasset wrote:


On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:


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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal




C# itself is heavily inspired by Delphi though, as it's another Anders
Hejlsberg project. I fail to see what the "spirit of the language" has to
do with anything as far as attributes, either.

Shouldn't the attribute tags just be put wherever it's easiest for the
compiler to deal with them?


Exactly our point.

That would be behind the declaration, where all other modifiers are put
(default, stored, nodefault, or all procedure and variable modifiers)

Deciding to put them in front of the declaration broke years of tradition,
and most certainly was not leveraging existing compiler infrastructure.



I think the vast majority of people care far more about how *useful
Pascal actually is in real life* than they do
about whether or not it fulfills some not-well-defined notion of "spirit".


I think even D7 pascal is useful in real life. I could easily work with it
still today, and need none of the things introduced afterwards. I am still
as productive as I was with D7.

Things that change my productivity are libraries to accomplish tasks, 
not language features.




Also, as far as I can tell, most of the people who use FPC would consider
the Delphi way to be the correct or normal way of doing things in the first
place.


For the features they introduced first, maybe.

But for operator overloading and (IIRC) generics, FPC introduced them first. 
FPC also introduced the ObjC dialect to be able to import the native interfaces 
of Mac.


Delphi decided to go another way in all of these cases. 
Were they correct or normal ? I don't think so. 
Did they consult with us ? No, they did not.


While we definitely want to be Delphi compatible, I don't think we're in
any way less of an authority on all things Pascal.

With the brain drain in Embarcadero of the last years, these days I would even 
claim the opposite.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[James Lee]

On 7/21/2018 1:43 PM, Ben Grasset wrote:


Shouldn't the attribute tags just be put wherever it's easiest for the 
compiler to deal with them?




That would be bending the language to fit the implementation, when it 
should be the other way around.


I think the vast majority of people care far more about 
how/usefulPascal actually is in real life/than they do
about whether or not it fulfills some not-well-defined notion of 
"spirit".




Not me.  No computer language is a one-size-fits-all solution, nor 
should it be - though we have several  languages to choose from that are 
trying to be.


Also, as far as I can tell, most of the people who use FPC would 
consider the Delphi way to be the correct or normal way of doing 
things in the first place.




Again, not me.  Several Delphi features were rushed to meet a release 
deadline and were not well thought out.


-Jim

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

Isn't Delphi compatibility a major ongoing goal of both FPC and Lazarus,
though?

On Fri, Jul 20, 2018 at 10:01 AM, R0b0t1  wrote:

> On Fri, Jul 20, 2018 at 12:20 AM, 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.
> >
>
> 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  -  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

[Ben Grasset]

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> 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  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>


C# itself is heavily inspired by Delphi though, as it's another Anders
Hejlsberg project. I fail to see what the "spirit of the language" has to
do with anything as far as attributes, either.

Shouldn't the attribute tags just be put wherever it's easiest for the
compiler to deal with them?

I think the vast majority of people care far more about how *useful
Pascal actually
is in real life* than they do
about whether or not it fulfills some not-well-defined notion of "spirit".

Also, as far as I can tell, most of the people who use FPC would consider
the Delphi way to be the correct or normal way of doing things in the first
place.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[R0b0t1]

On Fri, Jul 20, 2018 at 12:20 AM, 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.
>

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

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

[Ben Grasset]

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

[Bo Berglund]

On Thu, 19 Jul 2018 03:42:26 +0200, "Tomas Hajny"
 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Mark Morgan Lloyd]

On 18/07/18 20:45, Ryan Joseph wrote:

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 := 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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Martin Schreiber]

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

Re: [fpc-pascal] Syntax changes suggestions

[Reimar Grabowski]

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

[Tomas Hajny]

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

[Ben Grasset]

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

[Ben Grasset]

>  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

[Reimar Grabowski]

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

[Reimar Grabowski]

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

[Reimar Grabowski]

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

[Ryan Joseph]

> 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

[Ryan Joseph]

> 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

[Ben Grasset]

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

[Ben Grasset]

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

[Ben Grasset]

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

[R0b0t1]

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

[R0b0t1]

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

[Sven Barth via fpc-pascal]

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

[Sven Barth via fpc-pascal]

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

[Sven Barth via fpc-pascal]

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]

> 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

[R0b0t1]

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

[Ryan Joseph]

> 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

[Ryan Joseph]

> 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

[Florian Klaempfl]

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

[Sven Barth via fpc-pascal]

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

[Sven Barth via fpc-pascal]

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]

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

[Ryan Joseph]

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

[Ben Grasset]

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

Re: [fpc-pascal] Syntax changes suggestions

[Dekks Herton]

Ryan Joseph  writes:

>> On Jul 17, 2018, at 2:07 PM, Jim Lee  wrote:
>> 
>> And that's why I hesitate whenever someone comes along and says we should 
>> add  to Pascal
>
> I just want my life to be easier and to enjoy programming in Pascal as
> much as possible. If I’m doing work I don’t have to, merely knowing
> that Pascal has remained pure to the original specification is not
> very much comfort to me.

Thereby rests one of the problems of modern programming, choose the best
tool at hand for the project at hand. Trouble is so many only know 1 or
2 languages [looking at you java + python] people try to make them do
everything thus leading to half assed features + bloat.  

-- 
Regards.
 
PGP Fingerprint: 3DF8 311C 4740 B5BC 3867  72DF 1050 452F 9BCE BA00
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 13:28, Ryan Joseph wrote:
If I’m doing work I don’t have to, merely knowing that Pascal has 
remained pure to the original specification is not very much comfort 
to me.


I'm not advocating for purity.  I'm advocating for diversity.  I don't 
want to see Pascal become MumbleScript, or whatever the hot language of 
the week happens to be.


-Jim

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 07/17/18 11:50, Ryan Joseph wrote:


If lots of programmers using main stream languages like c++ are 
having a similar problem we are I think it’s incumbent for Pascal to 
at least consider if there is merit to the concern.






So if a lot of programmers find it bad to have to much freedom, then it 
is good if it is restricted?


Because take JavaScript, well there freedom of declaring variables is 
even less restricted, than was asked for in this thread.
But it seems that many JavaScript developers got frustrated with that. 
So much that the now have external tools to restrict that freedom


http://www.adequatelygood.com/JavaScript-Scoping-and-Hoisting.html
https://eslint.org/docs/rules/vars-on-top

This is not directly related to the original post/request.
But it shows that the statement quoted on top is severely dangerous.

Just because another language has a feature, or even because many use it 
(where it is not know what expertise those have, nor how many do not use 
it)...
Just because any of this, does by no means indicate that such a feature 
is any good at all.


Just because c++ has the feature does not mean that it solves any 
problem that c++ programmers would otherwise have. It can same as good 
mean the opposite.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 13:28, Ryan Joseph wrote:



On Jul 17, 2018, at 2:07 PM, Jim Lee  wrote:

And that's why I hesitate whenever someone comes along and says we should add 
 to Pascal

I just want my life to be easier and to enjoy programming in Pascal as much as 
possible. If I’m doing work I don’t have to, merely knowing that Pascal has 
remained pure to the original specification is not very much comfort to me.



That's why we have more than one language to create programs with. It's 
not possible to use one language in all domains with an equal amount of 
ease in each domain.


Think of human languages.  You cannot describe the operation of an 
internal combustion engine and the operation of performing an 
appendectomy with the same, plain English vocabulary.  Each requires the 
use of jargon specific to the domain.   So it is with programming 
languages - if we added the "jargon" necessary to cover every domain in 
a single language, that language would be unintelligible.


-Jim


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 17.07.2018 um 22:32 schrieb Ryan Joseph:



On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal 
 wrote:

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.

Maybe FPC needs a fork or something that keeps the original specification, or 
going the other way an experimental branch? Florian amongst others must be 
really annoyed with how this is all going and I sympathize with them.

FPC appears to have group of users who are purists (or something like that), 
Delphi users, and utilitarians (if that’s accurate a description) that want the 
language to evolve to meet current trends/demands of the industry, e.g. if 
there’s a good idea floating around out there I want to use it also.

Going forward how is this going to be resolved?
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.


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]

> On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> 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.

Maybe FPC needs a fork or something that keeps the original specification, or 
going the other way an experimental branch? Florian amongst others must be 
really annoyed with how this is all going and I sympathize with them. 

FPC appears to have group of users who are purists (or something like that), 
Delphi users, and utilitarians (if that’s accurate a description) that want the 
language to evolve to meet current trends/demands of the industry, e.g. if 
there’s a good idea floating around out there I want to use it also.

Going forward how is this going to be resolved?

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]

> On Jul 17, 2018, at 2:07 PM, Jim Lee  wrote:
> 
> And that's why I hesitate whenever someone comes along and says we should add 
>  to Pascal

I just want my life to be easier and to enjoy programming in Pascal as much as 
possible. If I’m doing work I don’t have to, merely knowing that Pascal has 
remained pure to the original specification is not very much comfort to me.

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

[Sven Barth via fpc-pascal]

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

Re: [fpc-pascal] Syntax changes suggestions

[Jim Lee]

On 07/17/18 11:50, Ryan Joseph wrote:



On Jul 17, 2018, at 12:24 PM, Jim Lee  wrote:

It has to fit the spirit of the language as well.

I don’t propose new features to copy other languages but I’ll mention other 
languages as evidence that more people than just myself have discovered some 
merit to the concept (i.e. a form of validation). When I say c++ does ___  too 
I take that as a good indication many other programers who work in a similar 
language had the same problem I did.

If lots of programmers using main stream languages like c++ are having a 
similar problem we are I think it’s incumbent for Pascal to at least consider 
if there is merit to the concern.



I disagree.

Pascal is a language (originally) intended to be used to teach 
structured programming concepts, and also to be a practical production 
language *in that same domain*.


When Mr. Wirth saw the merits of modular programming, he did not try to 
retrofit that functionality into Pascal - he instead created a new 
language, Modula-2, and later, Modula-3.


When Mr. Wirth later saw the merits of object oriented programming, he 
did not try to retrofit that functionality into Pascal or Modula - he 
instead created a new language, Oberon.


On the other hand, both Apple and Borland chose to extend their versions 
of Pascal with these newer concepts (and several others), turning Pascal 
into a multi-paradigm language.  That was in the day and time when 
commercial interests were more important than language design.  It was 
also a time when products were judged by the number of features 
included, not by their quality.


Now, I happen to think that both structured and modular programming 
belong together, and that Wirth could have added modular extensions to 
Pascal without destroying the spirit of the language.  However, what is 
known as "Object Pascal", to me, should be a separate language, with a 
different name.   Not better, not worse, just different.  And that's why 
I hesitate whenever someone comes along and says we should add of the day> to Pascal.


-Jim

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 17/07/2018 15:34, Michael Van Canneyt wrote:



On Tue, 17 Jul 2018, Vojtěch Čihák wrote:


Hi,

Lazarus has option "Show Class/Proc Hint" which displays method name 
(with light-green background) as the top line in source editor, only 
if the method's body is longer than number of lines in source editor.
Maybe new option "Show Proc var block" for permanent displaying var 
block in long methods would be enough? Jumps between code and 
declaration would not be needed.


If such a thing is implemented, then why not make it as the 'local 
variables' debug dialog, a separate floating window, maybe stay-on-top  ?


If you put it at the top of the source editor, it risks to take a lot 
of space out
of the source editor window, which kind of defeats the purpose, I 
suppose.

- Clone the current source editor, so you get another window.
- Scroll it to the block you want
- Resize it as needed
- Select "Lock Page" from the tabs popup menu
  (This will prevent, codetools from scrolling this window, if you 
navigate in the unit)


The result:
- you keep the variables in view
- if you "jump to declaration" of a variable (that is not visible in the 
current window), it will jump to it in the "locked" window
- if you jump back to previous location, you will be back in the 
unlocked window


___
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]

> On Jul 17, 2018, at 12:24 PM, Jim Lee  wrote:
> 
> It has to fit the spirit of the language as well.

I don’t propose new features to copy other languages but I’ll mention other 
languages as evidence that more people than just myself have discovered some 
merit to the concept (i.e. a form of validation). When I say c++ does ___  too 
I take that as a good indication many other programers who work in a similar 
language had the same problem I did.

If lots of programmers using main stream languages like c++ are having a 
similar problem we are I think it’s incumbent for Pascal to at least consider 
if there is merit to the concern.

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

[Jim Lee]

On 07/17/18 11:00, Ryan Joseph wrote:



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.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Well, if we keep with the cultural parallel, in all cultures people must 
eat, sleep, drink, be born and die, etc.  There are a number of 
commonalities simply because all involve humans.  My point is that a 
language should not adopt a feature simply because it is useful in 
another language.  It has to fit the spirit of the language as well.


Be careful of thinking that "useful" means "I can do the same thing in 
language X in the same way I do it in language Y".  Eventually, X == Y.


-Jim

___
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]

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

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

[Jim Lee]

On 07/17/18 07:49, Marco van de Voort wrote:


Worse, IMHO creeping unnecessary dialect change is worse than remaining
different. The spread of codebases over the various subdialects is worse than 
any
benefits these half assed extensions can ever have. It is spreading language
development thin instead of deep




Agreed.

This can be likened to the spread of globalization among cultures. 
Uniqueness and charm suffer at the hand of cross-pollination.


You can go almost anywhere in the world today and find icons of Western 
culture.  Starbucks in Sri Lanka.  McDonalds in Shanghai.


Likewise, "modern" programming languages are all converging on a common 
feature set, like cultural cross-pollination.


I prefer to have a variety of dialects and paradigms to choose from (and 
a variety of cultures) over a global sameness.


-Jim


___
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]

> On Jul 16, 2018, at 11:20 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Because they are programmers. They simply do it their way. And I'm especially 
> talking about code written by two different programmers, one storing the 
> instance somewhere and the other passing in an "auto" instance without 
> knowing that the other programmer is storing it somewhere.
>> Auto is a good idea. Allocating the “auto” classes the memory backend on the 
>> stack (my “stack alias” idea) is even better because you don’t need the 
>> memory manager too be involved.
> No, it's not. And we don't *want* to change the paradigm of TObject.

The reason we propose these things is because of a manifest observable need 
that we experience daily. We’re not proposing things like making Pascal garbage 
collected or ARC for all objects like new languages are. These are practical 
and optional solutions that programmers can use depending on their needs.

Firs off, yes I know this isn’t Pascal objects but look at this entirely 
predictable block of code that I found after searching for 10 seconds. 
Dynamically allocating memory which I *know* beyond a shadow of a doubt will 
only survive this function. There’s not going to be any passing around. I know 
this. 

Predictably at the end of the function I review all the memory I allocated and 
free it. Why couldn’t I just tell the compiler I want this freed at the time I 
declare the variable? I know then and I don’t want to think about it again. 
This is such an obvious pattern to optimize in the language. This is not that 
crazy guys.

colorSpace := CGColorSpaceCreateDeviceRGB;
bitmapInfo := kCGImageAlphaFirst or kCGBitmapByteOrder32Little;
provider := CGDataProviderCreateWithData(nil, bytes, bytesCount, nil);
imageRef := CGImageCreate(width, height, 8, 32, bytesPerRow, 
colorSpace, bitmapInfo, provider, nil, 1, kCGRenderingIntentDefault);

finalImage := NSImage.alloc.initWithCGImage_size(imageRef, 
NSMakeSize(width, height));
imageData := finalImage.TIFFRepresentation;
imageRep := NSBitmapImageRep.imageRepWithData(imageData);
//imageProps := 
NSDictionary.dictionaryWithObject_forKey(NSNumber.numberWithFloat(1), 
NSImageCompressionFactor);
imageData := imageRep.representationUsingType_properties(fileType, 
imageProps);
imageData.writeToFile_atomically(NSSTR(path), false);

// <——— freeing stuff ———>
CFRelease(provider);
CFRelease(imageRef);
CFRelease(colorSpace);
finalImage.release;

var
  colorSpace: CGColorSpaceRef;
  provider: CGDataProviderRef;
  imageRef: CGImageRef;
  finalImage: NSImage;


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

[Sven Barth via fpc-pascal]

Marco van de Voort  schrieb am Di., 17. Juli 2018, 16:50:

> To be honest, I'm wondering why Sven actually bothers to answer this
> nonsense.
>

Trust me, I wonder the same 

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

[Marco van de Voort]

In our previous episode, Mark Morgan Lloyd said:
> However, I do wish that people wouldn't resort to that same old 
> chestnut. There ought to be a Pascal discussion equivalent of Godwin's 
> Law: "sooner or later in any debate about a language feature somebody 
> will complain that it's too much like C".

That sounds very negative, but one must not forget that this only is a
response to a halfassed copy syntax-from-language-x request. And everything
is always demonstrated with 4 line examples, no analysis how it fits in the
parsing structure nothing.

To be honest, I'm wondering why Sven actually bothers to answer this
nonsense.
 
> Frankly, who cares? are we really all so insecure that we can't 
> accommodate even the suggestion that "our opponents" occasionally have a 
> good idea?

"Good idea" is terribly subjective as already made clear in this discussion,
opinions vary wildly.

Are we so insecure that we must copy every alien bit of syntax? No.

Worse, IMHO creeping unnecessary dialect change is worse than remaining
different. The spread of codebases over the various subdialects is worse than 
any
benefits these half assed extensions can ever have. It is spreading language
development thin instead of deep

P.s. people that disagree should start arguing for an unit/module concept
on C groups, and use the exact same reasoning. Please post the URL, and I'll
follow the thread with a bucket of popcorn.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Reimar Grabowski]

On Tue, 17 Jul 2018 12:04:19 +0200
Martin  wrote:

> But more troubling:
> You do no longer have a complete list of all local vars. That means, if 
> I want to add a (current style) local var "i", i may have to scan the 
> entire procedure (maybe hundreds of lines) to find if there already is a 
> nested "i"
Wouldn't you need to refactor this procedure anyway into 20 line chunks and 
nuke the guy that wrote it? ;)

Btw I don't support the proposed changes as I don't see the need to get all and 
every language on feature parity.
Languages do have different design philosophies which manifest in different 
feature sets. So there is always more to a feature than pure functionality.
I write nowadays mostly in languages which do have "block scope" and I really 
don't prefer one "scoping" over the other. Both make sense in the context of 
their respective language.
And Delphi for example introduced features in a vain attempt to stay relevant 
which where not in the spirit of pascal. Freepascal has no need to do this.

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

[Vojtěch Čihák]

Maybe it should be extension of Code Explorer.
 
I did a quick calculation, I have 1680x1050 laptop display and I can see 40 
lines of code in Source Editor, i.e. 39+1 method name for long methods.
If the var block has ~8 lines, then it would remain 31 lines for code, it is 
still accepatable. And I guess programmers have usually bigger displays.
 
V.
 
__

Od: Michael Van Canneyt 
Komu: FPC-Pascal users discussions 
Datum: 17.07.2018 15:34
Předmět: Re: [fpc-pascal] Syntax changes suggestions




On Tue, 17 Jul 2018, Vojtěch Čihák wrote:

> 
If such a thing is implemented, then why not make it as the 'local variables' debug 
dialog, a separate floating window, maybe stay-on-top  ?


If you put it at the top of the source editor, it risks to take a lot of space 
out
of the source editor window, which kind of defeats the purpose, I suppose.

Michael.

--

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal 
<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

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Vojtěch Čihák wrote:


Hi,
 
Lazarus has option "Show Class/Proc Hint" which displays method name (with 
light-green background) as the top line in source editor, only if the 
method's body is longer than number of lines in source editor.
Maybe new option "Show Proc var block" for permanent displaying var block in 
long methods would be enough? Jumps between code and declaration would not be 
needed.


If such a thing is implemented, then why not make it as the 'local variables' debug 
dialog, a separate floating window, maybe stay-on-top  ?


If you put it at the top of the source editor, it risks to take a lot of space 
out
of the source editor window, which kind of defeats the purpose, I suppose.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Mark Morgan Lloyd]

don't like looking at such C code, so why would I want that in Pascal


This is not my fight because TBH I'm inclined to avoid novel language 
features until I know that using them won't impact on some of the older 
kit I try to keep stuff compiled for.


However, I do wish that people wouldn't resort to that same old 
chestnut. There ought to be a Pascal discussion equivalent of Godwin's 
Law: "sooner or later in any debate about a language feature somebody 
will complain that it's too much like C".


Frankly, who cares? are we really all so insecure that we can't 
accommodate even the suggestion that "our opponents" occasionally have a 
good idea?


Besides which, in-block declarations predate C: it's the way that 
ALGOL-60 did it. And ALGOL-60 put the type before the variable in a 
declaration, had in-expression conditionals and so on: all things I've 
seen rejected offhand as "too much like C".


So come on chaps, at least get your history right and say that you 
prefer the Pascal way and won't have any ALGOL crap messing it up.


Pax vobiscum.

--
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Vojtěch Čihák]

Hi,
 
Lazarus has option "Show Class/Proc Hint" which displays method name (with 
light-green background) as the top line in source editor, only if the method's body is 
longer than number of lines in source editor.
Maybe new option "Show Proc var block" for permanent displaying var block in 
long methods would be enough? Jumps between code and declaration would not be needed.
 
V.
__

Od: Michael Van Canneyt 
Komu: FPC-Pascal users discussions 
Datum: 17.07.2018 12:30
Předmět: Re: [fpc-pascal] Syntax changes suggestions



Exactly: I do scope them. I make small routines.

Reducing scope to 5 lines in a routine of 20 lines is a waste of time.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal 
<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

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Tue, Jul 17, 2018 at 12:07:10PM +0200, Michael Van Canneyt wrote:

>On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
If you need to "reduce the scope of variables", your routines are too long to
begin with.

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.


And I'd fire any programmer that doesn't properly scope their variables,
just as you'd (hopefully) fire a programmer for using global instead of
function level variables.


Exactly: I do scope them. I make small routines.

Reducing scope to 5 lines in a routine of 20 lines is a waste of time.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Martin wrote:


On 17/07/2018 11:05, Henry Vermaak wrote:

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:

Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:


I have some suggestions of change to freepascal syntax, just to debate

(All are backward compatible)

- Declaring variables inside blocks, and loop variables


-> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.



[snip]



If you have a scoping problem in pascal, cut your code into smaller 
procedures.


Which is what I have been saying all along...

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 12:07:10PM +0200, Michael Van Canneyt wrote:
> >On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> If you need to "reduce the scope of variables", your routines are too long to
> begin with.
> 
> 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.

And I'd fire any programmer that doesn't properly scope their variables,
just as you'd (hopefully) fire a programmer for using global instead of
function level variables.

> But probably this whole answer is again too hyperbole :-)

It's not the hyperbole that really worries me too much, I like a bit of
that myself.  I'm worried about the knee-jerk reactions to good ideas.
Badly written responses like "reduces readability" is extremely
uncharitable without proper motivation and projects the image that
everyone on this list will just shoot down any improvement to their
beloved Pascal.

Anyway, not much to add to the subject without repeating myself.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:

On 17/07/2018 12:02, Henry Vermaak wrote:
>On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
>>*you* might do this, but there are enough developers that won't. I
>>already
>By not having this feature you're not giving anyone a choice.
>
By having this feature you are forcing everyone to use it.


No, why would you think that?  Nobody is forcing you to move your
variables into a block, just carry on as before if you don't like it.
Var sections for functions are optional, you can use global variables
for everything if you like.  No different to this.


The point under discussion is readability of code.

So, if I need to read someone elses code and this person uses this feature heavily, 
then I end up being confronted with it, the readability of his code for me

is reduced.

Pascal has always been lauded for being readable. 
I would like to keep it that way.


Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 17/07/2018 11:05, Henry Vermaak wrote:

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:

Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:


I have some suggestions of change to freepascal syntax, just to debate

(All are backward compatible)

- Declaring variables inside blocks, and loop variables


-> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.


On the contra side:

You could then have 2 or more differnt "i" variables in one procedure. 
That is hell to read.


Of course you could argue that you can only have a "nested" "i", if 
there is no local var "i" (current style local). And no other nesting.

Still 2 issues:
You could have 2 consecutive loops, with different typed "i". That can 
be confusing. (it may not be to you, but is still can be). Now you would 
need 2 different named loop counters (which to me is good).


But more troubling:
You do no longer have a complete list of all local vars. That means, if 
I want to add a (current style) local var "i", i may have to scan the 
entire procedure (maybe hundreds of lines) to find if there already is a 
nested "i" (or start the compiler to see if there is an error).
That would be a real burden added to pascal (and since I may have to 
work on other peoples code, it is no good to say that I could simply not 
use it)


--
Also lets make a distinction here:

What are we looking for:
A) Saving the (so called) work, of declaring the var on top? (Note: that 
the work is pressing ctrl-shift-c)?

B) Introducing vars with more fine grained scoping?

As for (A) I already expressed that I am against it. (there also is a 
recent thread on the forum where this was discussed, so look it up and 
read the arguments)


As for (B):
I don't know of any good proposal, but if there was it would have to be 
something like this: (I still dont like it, but if there was a good idea 
to bring it in shape...)


procedure Foo;
var
   a: Integer; // normal vor
scoped var
   b: integer;
begin
  //b can not be used here / it will be as if it does not exist
  a := bar();
  if a > 1 then begin
    scope b;  // must be first after begin
    b := 1;
  end;
  // b out of scope
  // scope for one statement (the entire for, including the begin end 
which as a compound statement is part of the for.

  with scope b do for b := 1 to 10 do ... ;
// alternatively
  using scope b do for b := 1 to 10 do ... ;
  scope b: for b := 1 to 10 do ... ;

So you still declare the var on top.

Again, this is to entertain an idea, which I personally do not like

If you have a scoping problem in pascal, cut your code into smaller 
procedures.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:
> On 17/07/2018 12:02, Henry Vermaak wrote:
> >On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> >>*you* might do this, but there are enough developers that won't. I
> >>already
> >By not having this feature you're not giving anyone a choice.
> >
> By having this feature you are forcing everyone to use it.

No, why would you think that?  Nobody is forcing you to move your
variables into a block, just carry on as before if you don't like it.
Var sections for functions are optional, you can use global variables
for everything if you like.  No different to this.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Martin wrote:


On 17/07/2018 12:02, Henry Vermaak wrote:

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
*you* might do this, but there are enough developers that won't. I 
already 

By not having this feature you're not giving anyone a choice.


By having this feature you are forcing everyone to use it.

(This has been explained plenty of times)


Exactly.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Martin]

On 17/07/2018 12:02, Henry Vermaak wrote:

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
*you* might do this, but there are enough developers that won't. I 
already 

By not having this feature you're not giving anyone a choice.


By having this feature you are forcing everyone to use it.

(This has been explained plenty of times)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:

On Tue, 17 Jul 2018, Henry Vermaak wrote:
>On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
>>Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
>>
>>> I have some suggestions of change to freepascal syntax, just to debate
>>>
>>> (All are backward compatible)
>>>
>>> - Declaring variables inside blocks, and loop variables
>>>
>>-> reduces readability -> no interest
>
>How can it reduce readability?  You move variables closer to where they
>are used, therefore reducing clutter in the main "var" section.

Pascal separates declaration from implementation. This proposal changes
that, it mixes implementation with declaration.


No, it will still separate the declaration, but just on the block level.


You are still mixing code with declarations.


When you look for a variable, you know it is in the declaration block.
If you need to start scanning the code, this is a major nuisance.


If you're in a block, you look at the "var" section of the block first,
then move up a block and repeat.  Calling it "a major nuisance" is
needless hyperbole.


I like hyperbole, one can never have too much hyperbole :)


In the above code, why do I want to see foo in the
main "var" block of the function?  It's just noise there, reducing
readability.


Of course not, that's where it belongs.


I can't count the misunderstandings in Javascript due to this 'feature'.


This feature makes you properly reduce scope of variables, I seriously
haven't met anyone that thinks this is a bad idea.  It's standard
programming practise in every language I've worked.


If you need to "reduce the scope of variables", your routines are too long to
begin with.

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.


But probably this whole answer is again too hyperbole :-)

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> Henry Vermaak  schrieb am Di., 17. Juli 2018,
> 11:05:
> 
> > On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> > > Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> > >
> > > > I have some suggestions of change to freepascal syntax, just to debate
> > > >
> > > > (All are backward compatible)
> > > >
> > > > - Declaring variables inside blocks, and loop variables
> > > >
> > > -> reduces readability -> no interest
> >
> > How can it reduce readability?  You move variables closer to where they
> > are used, therefore reducing clutter in the main "var" section.
> >
> 
> *you* might do this, but there are enough developers that won't. I already

By not having this feature you're not giving anyone a choice.

> don't like looking at such C code, so why would I want that in Pascal which
> avoided that problem?

What problem?  I'm not saying I want to mix declarations with code, the
var section should be at the top of the block/scope.  I don't even know
any C programmers that mix declarations with code.  This isn't the 80s.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Henry Vermaak  schrieb am Di., 17. Juli 2018,
11:05:

> On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> > Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> >
> > > I have some suggestions of change to freepascal syntax, just to debate
> > >
> > > (All are backward compatible)
> > >
> > > - Declaring variables inside blocks, and loop variables
> > >
> > -> reduces readability -> no interest
>
> How can it reduce readability?  You move variables closer to where they
> are used, therefore reducing clutter in the main "var" section.
>

*you* might do this, but there are enough developers that won't. I already
don't like looking at such C code, so why would I want that in Pascal which
avoided that problem?

Limiting variable scope is definitely a good thing, I sure hope you're
> not arguing against that.  That's why almost all languages encourage it.
>

I'm arguing against micromanaging the scope of a variable inside a
function.

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

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> On Tue, 17 Jul 2018, Henry Vermaak wrote:
> >On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> >>Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> >>
> >>> I have some suggestions of change to freepascal syntax, just to debate
> >>>
> >>> (All are backward compatible)
> >>>
> >>> - Declaring variables inside blocks, and loop variables
> >>>
> >>-> reduces readability -> no interest
> >
> >How can it reduce readability?  You move variables closer to where they
> >are used, therefore reducing clutter in the main "var" section.
> 
> Pascal separates declaration from implementation. This proposal changes
> that, it mixes implementation with declaration.

No, it will still separate the declaration, but just on the block level.
For example:

for i := 0 to n - 1 do
var
  foo: integer = 0;
begin
  // ...
end;

> When you look for a variable, you know it is in the declaration block.
> If you need to start scanning the code, this is a major nuisance.

If you're in a block, you look at the "var" section of the block first,
then move up a block and repeat.  Calling it "a major nuisance" is
needless hyperbole.  In the above code, why do I want to see foo in the
main "var" block of the function?  It's just noise there, reducing
readability.

> I can't count the misunderstandings in Javascript due to this 'feature'.

This feature makes you properly reduce scope of variables, I seriously
haven't met anyone that thinks this is a bad idea.  It's standard
programming practise in every language I've worked.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Mark Morgan Lloyd]

On 17/07/18 09:15, Henry Vermaak wrote:

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:> Santiago A.  schrieb am Mo., 
16. Juli 2018, 13:41:> > > I have some suggestions of change to freepascal syntax, just to debate> >> > (All are 
backward compatible)> >> > - Declaring variables inside blocks, and loop variables> >> -> reduces readability 
-> no interest
How can it reduce readability?  You move variables closer to where theyare used, 
therefore reducing clutter in the main "var" section.Limiting variable scope is 
definitely a good thing, I sure hope you'renot arguing against that.  That's why almost 
all languages encourage it.


Agreed, and that's /particularly/ the case with something like a loop 
control variable which should not be assumed to have a predictable value 
out-of-scope.


Wirth moved variables outside blocks to make Pascal incompatible with 
ALGOL, since after the disastrous ALGOL-68 fiasco he wanted to plough 
his own furrow. That doesn't necessarily make the decision a wise one.


--
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  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Michael Van Canneyt]

On Tue, 17 Jul 2018, Henry Vermaak wrote:


On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:

Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:

> I have some suggestions of change to freepascal syntax, just to debate
>
> (All are backward compatible)
>
> - Declaring variables inside blocks, and loop variables
>
-> reduces readability -> no interest


How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.


Pascal separates declaration from implementation. 
This proposal changes that, it mixes implementation with declaration.


When you look for a variable, you know it is in the declaration block.
If you need to start scanning the code, this is a major nuisance.
I can't count the misunderstandings in Javascript due to this 'feature'.

Given that the length a typical routine should not exceed 50 lines 
- i.e. fits on a modern screen - you can :

a) not have too many variables anyway.
b) see them at the glance of an eye at the top of your screen.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> 
> > I have some suggestions of change to freepascal syntax, just to debate
> >
> > (All are backward compatible)
> >
> > - Declaring variables inside blocks, and loop variables
> >
> -> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

In our previous episode, Santiago A. said:
> > And since the feature is implementable as an IDE macro (generating a nested
> > try except/finally) it doesn't make Ooccam's razor of usefulness to begin
> > with.
> The Occam's razor is that if it is so usefull that a macro is used a 
> lot, why not make it part of the languages avoiding depending on 
> external tools?

Because, like Sven said, there is a lot of crosstalk and fallout with a
language feature, and the IDE macro is limited to the handful of people that
for some reason have a high occurance of the feature in their business code
architecture.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Santiago A.]

El 17/07/2018 a las 10:11, Marco van de Voort escribió:

In our previous episode, Sven Barth via fpc-pascal said:

interested in why it is not supported.

At least Delphi Tokyo (10.2) does not support it.

If I remember the discussion correctly it came to light that some users
would need "try ? finally ? except ? end" while others would need "try ?
except ? finally ? end" and even some "try ? finally ? except ? finally
? end" or the like. With differences in opinion like this the idea was
dropped, cause this flexibility exists already, namely by using separate
blocks.

And since the feature is implementable as an IDE macro (generating a nested
try except/finally) it doesn't make Ooccam's razor of usefulness to begin
with.
The Occam's razor is that if it is so usefull that a macro is used a 
lot, why not make it part of the languages avoiding depending on 
external tools?


--
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Santiago A.]

El 16/07/2018 a las 21:27, Marco van de Voort escribió:

In our previous episode, Sven Barth via fpc-pascal said:

function)

In such cases, you don't declare it "auto". Just as you don't free a
pointer in the function you declare it if you pass the instance to another
code that stores it beyond the life time of the function


But you don't necessarily know that the function you call does that (think
third party code). And people *will* use this and don't think about the
consequences. So a system with automatic reference counting is safer and
that is what is planned, if at all.

Moreover the use case, dynamically instantiated classes with very local
scope is rare.
You must be kidding. You use local scope objects everywhere. The 
TStreams family is a clear example.


source/rtl/objpas/classes/classes.inc

//
function CollectionsEqual(C1, C2: TCollection; Owner1, Owner2: 
TComponent): Boolean;


  procedure stream_collection(s : tstream;c : tcollection;o : tcomponent);
    var
  w : twriter;
    begin
  w:=twriter.create(s,4096);
  try
    w.root:=o;
    w.flookuproot:=o;
    w.writecollection(c);
  finally
    w.free;
  end;
    end;

  var
    s1,s2 : tmemorystream;
  begin
    result:=false;
    if (c1.classtype<>c2.classtype) or
  (c1.count<>c2.count) then
  exit;
    if c1.count = 0 then
  begin
  result:= true;
  exit;
  end;
    s1:=tmemorystream.create;
    try
  s2:=tmemorystream.create;
  try
    stream_collection(s1,c1,owner1);
    stream_collection(s2,c2,owner2);
    result:=(s1.size=s2.size) and 
(CompareChar(s1.memory^,s2.memory^,s1.size)=0);

  finally
    s2.free;
  end;
    finally
  s1.free;
    end;
  end;


//
// auto version
//

function CollectionsEqual(C1, C2: TCollection; Owner1, Owner2: 
TComponent): Boolean;


  procedure stream_collection(s : tstream;c : tcollection;o : tcomponent);
    var
  w : twriter;auto;
    begin
  w:=twriter.create(s,4096);
 w.flookuproot:=o;
  w.writecollection(c);
    end;

  var
    s1,s2 : tmemorystream; auto;
  begin
    result:=false;
    if (c1.classtype<>c2.classtype) or
  (c1.count<>c2.count) then
  exit;
    if c1.count = 0 then
  begin
  result:= true;
  exit;
  end;
    s1:=tmemorystream.create;
    s2:=tmemorystream.create;
   stream_collection(s1,c1,owner1);
    stream_collection(s2,c2,owner2);
    result:=(s1.size=s2.size) and 
(CompareChar(s1.memory^,s2.memory^,s1.size)=0);

  end;
//

With "Auto", you save a lot of "try finally free" that add nothing to 
algorithm


You can argue against "auto" in the grounds of "Aesthetic symmetry ", 
"it's not explicitness pascal way", "it's not worth", "confusion mixing 
styles/paradigms" or other arguments I haven't thought. I asked 
expecting those arguments I hadn't thought about.
There may be valid arguments against, but when I read "local scope for 
classes is rare", I know I am in the grounds of a irrational 
resistance.  In such cases, a "For the sake of brevity, my vote is 
simply "no" to all your suggestions." is the best answer.


--
Saludos

Santiago A.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Marco van de Voort]

In our previous episode, Sven Barth via fpc-pascal said:
> > interested in why it is not supported.
> 
> At least Delphi Tokyo (10.2) does not support it.
> 
> If I remember the discussion correctly it came to light that some users 
> would need "try ? finally ? except ? end" while others would need "try ? 
> except ? finally ? end" and even some "try ? finally ? except ? finally 
> ? end" or the like. With differences in opinion like this the idea was 
> dropped, cause this flexibility exists already, namely by using separate 
> blocks.

And since the feature is implementable as an IDE macro (generating a nested
try except/finally) it doesn't make Ooccam's razor of usefulness to begin
with.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[el_es]

On 17/07/18 06:16, Sven Barth via fpc-pascal wrote:
> Am 16.07.2018 um 23:14 schrieb R0b0t1:
>> On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal 
>>  wrote:
>>> Am 16.07.2018 um 19:55 schrieb R0b0t1:
 
> - Try except finally blocks
 I can support this one, I am surprised it is not already
 supported. Wasn't this mentioned in another recent thread as
 existing? Does it exist in at least Delphi mode?
>>> 
>>> This is not supported and the last time it was discussed here on
>>> the mailing lists it was shot down (though I can't find the
>>> thread currently...). Also why should it exist in Delphi mode
>>> when Delphi does not support it? (Yes, there are some features
>>> that work in Delphi mode that Delphi doesn't support, but in
>>> generic the purpose of mode Delphi is to support Delphi code)
>> From my searching it is in (newer?) Delphi. I can't admit to being
>> a huge fan of "finally" (I don't typically use it myself) but I am 
>> interested in why it is not supported.
> 
> At least Delphi Tokyo (10.2) does not support it.
> 
> If I remember the discussion correctly it came to light that some
> users would need "try … finally … except … end" while others would
> need "try … except … finally … end" and even some "try … finally …
> except … finally … end" or the like. With differences in opinion like
> this the idea was dropped, cause this flexibility exists already,
> namely by using separate blocks.
> 
> Regards, Sven 

I just had an idea come to my head - what if Lazarus would handle
the tiers of try for us ? Maybe it should be a feature of the code editor,
to convert

try
  try
try
  code block 1;
except
  code block 2;
end;
  finally
code block 3;
  end;
except
  code block 4;
end;

into 

try
  code block 1;
except
  code block 2; 
finally
  code block 3;
except
  code block 4
end;

and variations thereof; Then no compiler changes are necessary.

Lazarus already has the 'collapsible code blocks', and this is not much
different. I'll post this idea to Lazarus list.

cheers,
el es

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Sven Barth via fpc-pascal]

Am 17.07.2018 um 04:48 schrieb Ryan Joseph:



On Jul 16, 2018, at 7:02 AM, Sven Barth via fpc-pascal 
 wrote:

Might come, though not in that way (take your example: what if you pass the 
instance to some other code that stores it beyond the life time of the function)

That’s what you guys said about my awesome “stack alias” idea. :) Seriously 
though I don’t for the life of me understand why programmers can’t be trusted 
to not do this. You can pass dangling pointers since forever but no one is 
asking pointers to be removed because they’re too dangerous.
Because they are programmers. They simply do it their way. And I'm 
especially talking about code written by two different programmers, one 
storing the instance somewhere and the other passing in an "auto" 
instance without knowing that the other programmer is storing it somewhere.

Auto is a good idea. Allocating the “auto” classes the memory backend on the 
stack (my “stack alias” idea) is even better because you don’t need the memory 
manager too be involved.

No, it's not. And we don't *want* to change the paradigm of TObject.

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

[Sven Barth via fpc-pascal]

Am 16.07.2018 um 23:14 schrieb R0b0t1:

On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
 wrote:

Am 16.07.2018 um 19:55 schrieb R0b0t1:



- Try except finally blocks

I can support this one, I am surprised it is not already supported.
Wasn't this mentioned in another recent thread as existing? Does it
exist in at least Delphi mode?


This is not supported and the last time it was discussed here on the mailing
lists it was shot down (though I can't find the thread currently...).
Also why should it exist in Delphi mode when Delphi does not support it?
(Yes, there are some features that work in Delphi mode that Delphi doesn't
support, but in generic the purpose of mode Delphi is to support Delphi
code)

 From my searching it is in (newer?) Delphi. I can't admit to being a
huge fan of "finally" (I don't typically use it myself) but I am
interested in why it is not supported.


At least Delphi Tokyo (10.2) does not support it.

If I remember the discussion correctly it came to light that some users 
would need "try … finally … except … end" while others would need "try … 
except … finally … end" and even some "try … finally … except … finally 
… end" or the like. With differences in opinion like this the idea was 
dropped, cause this flexibility exists already, namely by using separate 
blocks.


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]

> On Jul 16, 2018, at 1:27 PM, Marco van de Voort  wrote:
> 
>> But you don't necessarily know that the function you call does that (think
>> third party code). And people *will* use this and don't think about the
>> consequences. So a system with automatic reference counting is safer and
>> that is what is planned, if at all.
> 
> Moreover the use case, dynamically instantiated classes with very local
> scope is rare.

1) if you call a function that has an “auto” variable how does that affect the 
caller? I don’t see how it could.

2) Huh? I always allocate classes in functions. All the time. I do it so often 
I want a language feature to do clean up for me. This is also a way to 
deallocate classes with auto members so you don’t need to override the 
destructor all the time. 

c++ does this using classes on the stack and it’s ubiquitous. In FPC we need to 
allocate the memory and call free every single time, even in local scope when 
we know we don’t need the class anymore. It’s such an obvious feature I don’t 
understand how it gets so much resistance.

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]

> On Jul 16, 2018, at 11:55 AM, R0b0t1  wrote:
> 
> Declarations inside blocks I am unable to support. Declarations as
> loops I *might* be able to support, but once you go from a C-like
> language to Pascal and get used to predeclaring variables it starts to
> become nice. You don't have to figure out where things are.

but isn’t “i” for loops an exception? I have i:integer; in so many places in my 
code it’s safe to assume at this point what I want.

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]

> On Jul 16, 2018, at 7:02 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Might come, though not in that way (take your example: what if you pass the 
> instance to some other code that stores it beyond the life time of the 
> function) 

That’s what you guys said about my awesome “stack alias” idea. :) Seriously 
though I don’t for the life of me understand why programmers can’t be trusted 
to not do this. You can pass dangling pointers since forever but no one is 
asking pointers to be removed because they’re too dangerous.

Auto is a good idea. Allocating the “auto” classes the memory backend on the 
stack (my “stack alias” idea) is even better because you don’t need the memory 
manager too be involved.

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]

> On Jul 16, 2018, at 8:27 AM, Santiago A.  wrote:
> 
>> - Autofree pointers
>> 
>> Might come, though not in that way (take your example: what if you pass the 
>> instance to some other code that stores it beyond the life time of the 
>> function) 
> In such cases, you don't declare it "auto".

Yes exactly


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

[Ralf Quint]

On 7/16/2018 8:36 AM, Anthony Walter wrote:

To the OP:

For the sake of brevity, my vote is simply "no" to all your suggestions.

+1



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
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]

On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
 wrote:
> Am 16.07.2018 um 19:55 schrieb R0b0t1:
>>
>>
>>> - Try except finally blocks
>>
>> I can support this one, I am surprised it is not already supported.
>> Wasn't this mentioned in another recent thread as existing? Does it
>> exist in at least Delphi mode?
>
>
> This is not supported and the last time it was discussed here on the mailing
> lists it was shot down (though I can't find the thread currently...).
> Also why should it exist in Delphi mode when Delphi does not support it?
> (Yes, there are some features that work in Delphi mode that Delphi doesn't
> support, but in generic the purpose of mode Delphi is to support Delphi
> code)

From my searching it is in (newer?) Delphi. I can't admit to being a
huge fan of "finally" (I don't typically use it myself) but I am
interested in why it is not supported.

>>
>> FPC is already lacking in some major ways compared to Delphi. The main
>> one I can think of is anonymous functions. If anyone could implement
>> that the community would benefit immensely.
>
>
> As I had already written you on the Forum (
> http://forum.lazarus.freepascal.org/index.php/topic,39051.msg269034.html#msg269034
> ) this is WIP and you could help the author if you wanted.
>

My apologies, I think I stopped checking the forum as regularly before
you posted. I will look for the code.

Cheers,
 R0b0t1
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal