New language features?

[LV]

Maybe just new language startup for Pascal++ or Pascal#? 

[marcov]

There are umpteen Pascal .NET dialects, including Component Pascal as original .NET language by Microsoft it self (though despite the name is more an Oberon)

[LV]

There are umpteen Pascal .NET dialects, including Component Pascal as original .NET language by Microsoft it self (though despite the name is more an Oberon)

thanks for clarification

[Fibonacci]

@440bx: Inline types? Not such a bad idea.

Assuming X is pointer to some buffer and at offset 0x100 you want to change something

Code: Pascal  [Select][+][-]

1. with PByte(X+$100)^ as type packed record
2.   d: dword;
3.   s: array[0..99] of char;
4. end do begin
5.   d := 123;
6.   s := 'new string value';
7. end;

I wouldnt mind.

Inline constants? Why not.

And if someone is going to say I'm exaggerating... I'd like to point out that the argument for inline variables is _convenience_.  I claim it is also very convenient to do away with having to pre-declare variables (but, I'd never claim it's a good idea.)

For this reason Delphi implemented it. Maybe in production grade code you move the variables to the top (like @Warfley mentioned linux kernel has), but while implementing a new feature you realilze you need more and more variables, then you realize you dont use them anymore, why jump up and down each awhile. You could just declare vars inline, after code is complete make it nice, move variables to the top, add error checking etc.

This inline var + type I would use. I often call functions that take as argument callback function + additional parmeter as Pointer, so I could pass nice struct with this Pointer

Code: Pascal  [Select][+][-]

1. var somevar = record
2.   d: dword;
3.   s: string;
4. end = (
5.   d := 123;
6.   s := 'string';
7. end;

Or even shorter

Code: Pascal  [Select][+][-]

1. var somevar = record
2.   d: dword = 123;
3.   s: string = 'string';
4. end;

If I could do this it would be easier to pass many types via one buffer as Pointer. While developing it would be useful. No need to jump above procedure to declare type.

Few days ago I needed to SendMessage (WinApi) EDITSTREAM structure as LPARAM Pointer, it crashed on x64. Turned out record in Windows unit is not PACKED and on x64 padding was added which caused app to CRASH. I had to define my own fixed record type. If this was possible, I would just pass @somevar, without declaring type.

[440bx]

@Fibonacci,

Honestly, I consider the stuff you mentioned a disgrace.  The building blocks of quite a mess.

What I personally believe would be a genuine improvement that would allow a programmer to write cleaner and clearer code are inline scopes.  A short explanation/example of what those are can be found at https://forum.lazarus.freepascal.org/index.php/topic,43172.msg323311.html#msg323311

Inline scopes give you all the benefits of inline variables, inline types and constants (without any of the messy downsides) _and_ in addition to that they also allows for conditionally exiting the scope if necessary (which is one of the reasons functions/procedures are created that should NOT exist - because they only exist to provide a way to conditionally exit them.)

[Fibonacci]

I am sorry that you perceive this as a disgrace to the Pascal language. IMHO such extensions would be useful. Of course my code snippets are just quick examples, final syntax would look and work differently.

As for exit in nested begin-end block I agree. Break keyword should escape from any current scope, not just loops.

But you can do that with anonymous functions.

Code: Pascal  [Select][+][-]

1. {$modeswitch anonymousfunctions}
2.  
3. procedure test;
4. var
5.   s: string;
6. begin
7.   s := 'AAA';
8.  
9.   procedure
10.   var
11.     s: string;
12.   begin
13.     s := 'BBB';
14.     writeln('1 = ', s);
15.  
16.     exit; //escape
17.  
18.     writeln('shouldnt print 1');
19.   end();
20.  
21.   procedure
22.   begin
23.     writeln('2 = ', s);
24.  
25.     exit; //escape
26.  
27.     writeln('shouldnt print 2');
28.   end();
29.  
30.   writeln('3 = ', s);
31. end;
32.  
33. begin
34.   test;
35.   readln;
36. end.

1 = BBB
2 = AAA
3 = AAA

See? You CAN do that. But you see it as "genuine improvement" you say. So I ask you why not use anynomous functions? Its already available, go use it.

Many things are already available and can be used, but you want to exit a scope with the break keyword.

This is what you want, and I want inline variables (even inline types), nameless records and multiple case-of in records, and allow case-of not only at the end of the record.

These are improvements and shortcuts. Everything can be already done "some way". But it can be made simpler.

[440bx]

Anonymous functions are a relatively new thing and, yes, they can be used as a "funky" inline scope.

There are two problems with them, first, there is probably a stack frame associated with them, something which is unnecessary with inline scopes.  Second, it's simply weird to have to put an open and close parenthesis at the end for the code to execute, that's not intuitive.  With inline scopes, the code you read is what executes, no need for extraneous parentheses anywhere.

Additionally, the fact that the procedure is anonymous means it has no name, that's not good because there should be a name to expose/identify what the function/procedure does (what's its purpose!.)

I concede that anonymous functions can be used to implement inline scopes but, I see them as deficient band-aids as well as quite likely inefficient (the inefficiency  would come from them establishing an unnecessary stack frame which has to be taken down upon exit.)

There are other problems/deficiencies from a language design standpoint such as, the procedure name is or isn't required depending on _where_ the procedure is declared, i.e, depending on the location, it is a nested procedure instead of an anonymous one.  The parentheses would be an error for a nested function, while optional for an anonymous one _and_, worse, quite easy to inadvertently omit. 

Just because something can be used doesn't mean it's good.

[marcov]

The original Occam's razor was to gun for extensions that somehow have a multiplying effect, e.g. make something new possible, rather than micro syntax navelgazing.

Such an effect can be to fulfill some role deep in a framework, in cross thread workings (like anonymous methods) etc etc.

See https://www.freepascal.org/faq.html#extensionselect

[Bogen85]

Anonymous functions are a relatively new thing and, yes, they can be used as a "funky" inline scope.

New to free pascal, many decades old in other programmings languages.

Just because something can be used doesn't mean it's good.

Not every language feature is useful to everyone, and not every feature is useful in a general sense.

Additionally, the fact that the procedure is anonymous means it has no name, that's not good because there should be a name to expose/identify what the function/procedure does (what's its purpose!.)

Anonymous functions are typically passed or returned to something else.
It does not always make sense to name them, the receiver has a name for what is being received, as far as returning, it depends on the context.

Free Pascal already has nested functions, and those are named. Those can be used as function references just like anonymous functions.

In some situations it makes sense to just return the reference to an already named function that matches the function reference type.

It all depends on context.

Anonymous functions are not a replacement for named functions, especially in pascal.

Just because something can be used doesn't mean it's good.

That is subjective and depends on the programmer's view and use cases for Pascal, and how their programming style has been shaped by other programming languages and experience.

[Bogen85]

Anonymous functions are a relatively new thing and, yes, they can be used as a "funky" inline scope.

There are two problems with them, first, there is probably a stack frame associated with them, something which is unnecessary with inline scopes.  Second, it's simply weird to have to put an open and close parenthesis at the end for the code to execute, that's not intuitive.  With inline scopes, the code you read is what executes, no need for extraneous parentheses anywhere.

If one is calling the function right away there then this (to me at least) is not a place where an anonymous function should be used.
It just makes the code look strange and since it is not passed to something else (everything already known within this scope) then to me it is extra overhead just to create and teardown a closure when the code could have just been there without the anonymous function wrapper, or in a nested function within the same scope.

[piola]

Ok you got me here. But still inline variables IMHO are must have.

I wouldn't say that comprehensive support for inline variable were a must have. Imho, there's only one use case where having inline variables would be of great aid:

Code: [Select]

for var i := 1 to 10 do ...

[Warfley]

How much effort would it take to implement inline variables? When I was modifying compiler source to disable/overwrite/mangle/shorten RTTI as much as possible because I so hate it what I saw was codebase so huge, complex, so hard to change, so hard to add a new feature, to extend syntax. Commits on gitlab are mostly little bugfixes for RTL, nothing going on with the compiler itself.

Delphi has them for 5 years.

To answer your question more precisely, it took me around 1 hour to build the attached patch, which compiles the following:

Code: Pascal  [Select][+][-]

1. program Test;
2.  
3. {$Mode ObjFPC}{$H+}
4. {$ModeSwitch InlineVariables}
5.  
6. var
7.   x: Double;
8. begin
9.   Write('Enter Float: ');
10.   ReadLn(x);
11.   WriteLn('Entered: ', x);
12.  
13.   begin
14.     Write('Enter Integer: ');
15.     var x: Integer;
16.     ReadLn(x);
17.     WriteLn('Entered: ', x);
18.   end;
19.  
20.  
21.   begin
22.     Write('Enter String: ');
23.     var x: String;
24.     ReadLn(x);
25.     WriteLn('Entered: ', x);
26.   end;
27.  
28. end.

Note, I haven't written any test cases aside the above or ran the existing tests so this will probably break something.

PS: I still don't like the idea, but this sort of thing is just a fun little thing to do

[Edson]

To answer your question more precisely, it took me around 1 hour to build the attached patch, which compiles the following:

Code: Pascal  [Select][+][-]

1. program Test;
2.  
3. {$Mode ObjFPC}{$H+}
4. {$ModeSwitch InlineVariables}
5.  
6. var
7.   x: Integer;
8. begin
9.   Write('Enter Float: ');
10.   ReadLn(x);
11.   WriteLn('Entered: ', x);
12.  
13.   begin
14.     Write('Enter Integer: ');
15.     var x: Integer;
16.     ReadLn(x);
17.     WriteLn('Entered: ', x);
18.   end;
19.  
20.  
21.   begin
22.     Write('Enter String: ');
23.     var x: String;
24.     ReadLn(x);
25.     WriteLn('Entered: ', x);
26.   end;
27.  
28. end.

Note, I haven't written any test cases aside the above or ran the existing tests so this will probably break something.

PS: I still don't like the idea, but this sort of thing is just a fun little thing to do

Although I like the facility of this "like .NET" style for variable declaration, I think this definitively break the spirit, mind and body of Pascal. This make unnecessary the existence of VAR blocks like Pascal define.

I would like to have this in a language but I don't call this language "Pascal".  Maybe it' time for Pascal++ like someone proposed.

[domasz]

I don't inline variables, they are not in spirit of Pascal BUT:
1) Delphi has them
2) It makes it easier to port code from C-like languages to Pascal

[lainz]

Doesn't matter if I like or not inline variables. If I will not add them to the language or I can't help to determine the way.