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

(All are backward compatible)

- Declaring variables inside blocks, and loop variables
- Autofree pointers
- Try except finally blocks
- Private declarations in implementation

some of them can be found in
https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions

**declaring variables inside blocks, and loop variables**

var
  Number1,number2:Integer;
  f:textFile;
begin
   <...>
   while not eof(f) do begin
      Readln(f,number1,number2);
      if number1>number2 then
        begin
          var swapnum:Integer;// declaring in a block. Even initializing
it, var swapnum:Integer:=Number1;
          swapnum:=number1;
          number1:=number2;
          number2:=swapnum;
        end;
   end;
   <...>
end;

---------------

for var i:integer:=1 to 100 do
    begin
       <...>
    end;

---------------

**autofree pointers**

procedure foo;
   var s:TStringList; auto;// you add "auto", like absolute
begin
   s:=TStringList.create;
   <..>
   // s is freed automaticallyat the end of block, without try finally
end;

That combined with declaring inside blocks would make things less verbose avoiding a lot of try finally.

**try except finally blocks**

instead of

------------------
 try
    try
      <...>
    except
       <...>
    end;
 finally
    <...>
 end;
------------------

just write

------------------
 try
    <...>
 except
    <...>
 finally
    <...>
 end;

**Private declarations in implementation**

In the implementation, being able to implement a private method without declaring it in the interface part.
You just write:

-------------------------
implementation
procedure TMyClass.MyPrivateMethod;
begin
   <...>
end;
-------------------------

And if it is not declared in the interface part, it is assumed as private. It is a private method, nobody is aware of it outside of the implementation, it can't be used in derived classes, it unnecessary in the interface, and needn't to be declared.

The same could be applied for private vars. :

--------------------------
implementation
var
  TMyClass.privateVar: Integer;
--------------------------

I suppose this is more difficult with variables than with methods, because of reserving memory etc, but it would be handy.

Santiago A. wrote

for var i:integer:=1 to 100 do    begin       <...>    end;

What is the benefit? Poorer readability?

g
Michael

Some can be considered regressions, not progression.

autofree pointers will be available with management operators, I suppose. probably try except finally blocks is still doable.

But declaring variables inside code blocks makes for really bad readability and - worse - possibly error prone code.

What to do with scope rules ?

Var
   C : integer;
begin
   C:=1; // C is integer
   // New block, hence new scope
   for var c:string in List do begin
     ... // C is string
   end;

Which is IMO error prone.

the alternative is the javascript way, elevate the "c" in the for loop to a procedure local variable, in which case the above should result in an error, and which is a major source of problems.

Either way, I don't think this is very desirable.

Michael.

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

-> reduces readability -> no interest

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

- Try except finally blocks

This had been proposed some time ago and was declined after quite some discussion (either here or on fpc-devel).

- Private declarations in implementation

Again this reduces readability and thus no interest.

Regards,
Sven

I think the opposite.
The nearer the declaration to the code where you use it, the better.

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

Once again, I think the opposite.
It's not very readable a class where you have to skim through 100 lines of private declaration that you don't care, because you can do nothing with them.

It is a local variable to the block, the scope is the from the declaration to the end of the block. Nevertheless, I think that declarations should be at the beginning of the block, before any executable statement, so the scope is the block.
Ada, has the structure
-------------
if  a>b then
   Declare
     s:string='aaaa';
begin
      <...>
end;
end if;
--------------

I just say that the nearer the variable to the place you use it, the better. Particularly in the case of FOR loops it makes a lot of sense. In fact, the variable shouldn't make sense before or after the loop. Why not declare it just in the loop? Ada does it.

I don't think Ada is a language of dirty hacks.

What is a block?
a) Each individual statement
b) a compound statement

** if a, then your examble
   begin
      var a: integer;  // statement ends at ";" the scope ends too       foobar;

** if b:
Var
   C : integer;

begin // <<<<<<<<<< block "1" begins here
  C:=1; // C is integer
  // New block, hence new scope // <<<<<<<<<<<< see question above, where exactly is the new block?
  for var c:string in List do begin // <<<<<<<<<< block "2" begins after/with the "begin" statement
    ... // C is string
  end;

var c:string is therefore part of block 1. And valid to the end of block 1, which includes the code after the loop.

Nevertheless, I think that declarations should be at the beginning of the block, before any executable statement, so the scope is the block.

well in your "for" loop example, that is not the case. the "var" is not at the start of the block. (whatever the block is).

So you already contradict yourself.

Besides that, the discussion has been had plenty of times already, most recently on the forum.
So the question is not "why this feature", but "what makes this instance of the discussion different"?

And please do not say "if it is requested so many times", because if this was to be an argument, then I could request a million times to replace "begin" with "{", but at the same time keep "end" as keyword. If I request it often enough, it would have to be good, or would it not?

To the OP:

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

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.

- Autofree pointers

Useful but it looks like this will not be a base language feature.

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

- Private declarations in implementation

Typically you should "hide" things in either a private class method or in method variables.

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.

I've looked, on and off, but not been able to make a lot of progress.

Cheers,
R0b0t1

Santiago A. schrieb am Mo., 16. Juli 2018, 16:27:

I disagree. The way it is in Pascal you can easily see which variables are used and what type they have while with inline declarations you need to skim the whole routine. And trust me, only because a variable *can* be declared close to its use it does not mean that it *is*.

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.

Again all the declarations reside in one place currently, namely the declaration of the class. With your idea I'd have to search the whole unit not to mention that the order of declaration would be important as well just like it had been in procedural Pascal due to the single pass nature of the language.

Regards,
Sven

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

scope is rare.

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)

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.

Regards,
Sven

huge fan of "finally" (I don't typically use it myself) but I am interested in why it is not supported.

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

Cheers,
R0b0t1

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

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

Yes exactly!!!!

Regards,
Ryan Joseph

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

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

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

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

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

In our previous episode, Sven Barth via fpc-pascal 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.

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.classtypec2.classtype) or
       (c1.countc2.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.classtypec2.classtype) or
       (c1.countc2.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.

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?

In our previous episode, Santiago A. said:

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.

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

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.

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.

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

Spot on, you can pretty much eliminate that class of bug with this.

Henry

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

*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

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

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.

You are still mixing code with declarations.

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.

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.

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

(This has been explained plenty of times)

Exactly.

Michael.

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

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.

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

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

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.

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

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.

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

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.

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

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.

----------

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.

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.

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

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

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

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

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

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

- 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

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 <feature of the day> to Pascal.

-Jim

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

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 <feature of the day> 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

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

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

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

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

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

Thereby rests one of the problems of modern programming, choose the best tool at hand for the 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.

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 <

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

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

Ryan Joseph schrieb am Mi., 18. Juli 2018,
19:15:

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

Ryan Joseph schrieb am Mi., 18. Juli 2018,
19:00:

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

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

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

You should fire the whole compiler development team then ;)

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

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

Ryan Joseph schrieb am Mi., 18. Juli 2018,
21:37:

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

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

Ryan Joseph schrieb am Mi., 18. Juli 2018,
21:41:

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

R0b0t1 schrieb am Mi., 18. Juli 2018, 21:46:

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

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.

I understand, but you can get close. That is why I mentioned type safety. Ignoring those things seems kind of anti-Pascal way.

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 <

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

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

Well, the array TFPGList uses for storage would still be allocated on the heap in any case no matter what...

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

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.

1) For high performance situations it really does matter... <snip> I was doing a game engine recently and doing the create/free thing when I knew I didn’t have to was painful.

For high performance in a game engine you should not allocate/deallocate memory in the game loop at all (can be done, have done it*, so no arguing there). Increases the performance and frees you of doing "the create/free thing", that's killing two birds with one stone. Outside the game loop you do not need such a 'high performance' anymore.

R.

*The game uses procedural/random level generation and depending on skill there can be over 300 levels in a single run, with all allocation/deallocation happening before/after a run.

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.

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?

Yawn, more F.U.D.

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)

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.

Ben Grasset wrote

For example, does *anyone *actually think the strange "lowercase everything" capitalization style the compiler uses is "readable" nowadays?

Yes.

Martin

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.

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.

+1

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

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.

If a feature works as intended and is useful (which is all that matters), how is it "blind copying"?

Ben Grasset wrote

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

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.

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.

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

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via 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.

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

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.

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

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

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.

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

Ben Grasset wrote

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.

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

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

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.

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

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

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.

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

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