I hope FreePascal can support syntax like Python's f'string {variable}' or ...

[Zvoni]

Formatis just a function with a certain syntax, and you constantly have to cross-reference between the placeholders and the variables—it's nowhere near as readable as f-strings.

That's true but, that problem is not present in WriteStr and WriteStr is fairly capable, likely as capable as Python's f'string (but I could be wrong about that... I'm no expert in Python.)

But my point is, I’m not actually using WriteStr. The same issue applies in other statements too. For example, Edit1.Text = f'{userName} has done.';The f-string syntax is applied consistently across all the contexts where it’s needed.

it will never work in Pascal, because Python's "F-String"-Variable interpolation is evaluated and processed at Runtime, while in Pascal all operations (Replace and concatenation) have to be resolved at compile-time.

[Zvoni]

@Zvoni

Write freepascal like this may be nice （do not care var type, inttostr(), timetostr() ? no ）:
 Edit1.Text = f'{userName} has done.';

Then program whatever you are programming in python, and not in Pascal.

Wrong tool.
You are trying to tighten a Screw with a pipe wrench.

I'm out of here

[xiyi0616]

@Zvoni

Write freepascal like this may be nice （do not care var type, inttostr(), timetostr() ? no ）:
 Edit1.Text = f'{userName} has done.';

Then program whatever you are programming in python, and not in Pascal.

Wrong tool.
You are trying to tighten a Screw with a pipe wrench.

I'm out of here

Just discussing — Lazarus, as a compiled language, definitely has its strengths. I’m bringing this up precisely because I want it to be better, and I’m actually using it. And Format is at Runtime ... (If you don’t want to discuss it, that’s okay.).

[Handoko]

I do like the idea of making fingers to type less on the keyboard.

But do not care var type?

That is a big no 

Because Pascal user understand how important strong typing is. Here is the reason why weak typing is bad:
https://www.youtube.com/watch?v=aXOChLn5ZdQ

[xiyi0616]

I do like the idea of making fingers to type less on the keyboard.

But do not care var type?

That is a big no 

Because Pascal user understand how important strong typing is. Here is the reason why weak typing is bad:
https://www.youtube.com/watch?v=aXOChLn5ZdQ

What I mean is that the compiler knows the variable types at compile time. Alright, I suppose that would involve a significant amount of work. I was just discussing the idea.

[Martin_fr]

Sadly in Pascal the only options are slow & error-prone format strings or inflexible & cumbersome  Write*  builtins.
Your best bet would be to make a suggestion for @Fibonacci in this thread.

For speed you need to compare with "writestr".

However, comparing speed between any pre-compiled and any script (byte code) based language may generally be tricky. Byte code interpreter can do different tricks than compilers. There are situations in which they can optimize stuff at runtime, according to the actual use at runtime. That is something a compiler can by definition not do (unless is generates self modifying code). So there are cases where byte code can be faster. And vice versa.

In general, scripts and compiled (machine code) languages have different areas of application. Use each for what they are good for. Don't try to substitute one by the other. (Unless you also call your plumber to get your electrics wired)

I'm not an expert, so I'm just speaking from a user's perspective. With the Formatapproach, the parameters inside the brackets have to be written in sequence according to the placeholders in the preceding format string.

No, they don't. And you can even supply params that you don't use, you just have to supply at least all those that you use.

Format can refer to arguments by their index.

[xiyi0616]

I'm not an expert, so I'm just speaking from a user's perspective. With the Formatapproach, the parameters inside the brackets have to be written in sequence according to the placeholders in the preceding format string.

No, they don't. And you can even supply params that you don't use, you just have to supply at least all those that you use.

Format can refer to arguments by their index.

You're right. I was just sharing my personal thoughts on what I think could be better.

[jamie]

pascal also has abstracts that allow for variable input and any types on the fly.

Variants and open arrays come to mind along with chaining the objects for daisy chain statements.

ding in.

Jame

[marcov]

it will never work in Pascal, because Python's "F-String"-Variable interpolation is evaluated and processed at Runtime, while in Pascal all operations (Replace and concatenation) have to be resolved at compile-time.

It could maybe be resolved over extended RTTI, but how does the interpreting function get access to the calling scope?  But since Pascal constant strings literals don't have escapes, how would you make { and } in a backwards compatible way?

Anyway, sufficient to say that the chances on such an invasive functionality getting in are near zero in this way.

If the scope issue can be solved, maybe a pseudo function syntax would be possible that can also support escaping (just like format does). It is a good exercise for a junior developer to try. Maybe something for the "FPC unleashed" branch?

[Khrys]

Sadly in Pascal the only options are slow & error-prone format strings or inflexible & cumbersome  Write*  builtins.

I've never attempted to compare the performance of FPC output facilities with those of Python but, I find it a bit difficult to believe that interpreted I/O functions would be faster than compiled I/O code.

In addition to that, I can't think of any case where Python f'string can do something that can't be fairly easily done with WriteStr. 

Seems to me there is nothing that can be done with one that cannot be done with the other. Since I'm very far from being a Python expert, correct me if I'm wrong and, in that case, one or more examples of those cases would be great.

What I meant to say is that in FPC you'll have to make a choice between fast  (WriteStr  et al. with special compiler support) and somewhat free-flowing (Format,  executes at runtime).

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

1. WriteLn('By ', FreeFlowing, ', ', I, ' mean not having to ', Think, ' about spaces, ', 'commas and ', Quotes, ' all the time');

WriteStr always requires a variable; it can't be used expressions.

Write*  format specifiers (if you can call them that) are somehow even less intuitive than the equivalent functionality in  printf/Format  templates, which is quite an achievement.

How often do you actually need to print floats in scientific notation? How about controlling the decimal separator without modifying  DefaultFormatSettings? Why do all these things require additional function calls?

[440bx]

How about controlling the decimal separator without modifying  DefaultFormatSettings? Why do all these things require additional function calls?

Actually, I'm one who believes I/O belongs in libraries not in the language itself (a la C.)  As a result, IMO, Pascal already does more than it should but, I have to admit that there are limitations in what it can do at the language level, which is the reason there are additional library functions for I/O.

[Zvoni]

it will never work in Pascal, because Python's "F-String"-Variable interpolation is evaluated and processed at Runtime, while in Pascal all operations (Replace and concatenation) have to be resolved at compile-time.

It could maybe be resolved over extended RTTI, but how does the interpreting function get access to the calling scope?  But since Pascal constant strings literals don't have escapes, how would you make { and } in a backwards compatible way?

Anyway, sufficient to say that the chances on such an invasive functionality getting in are near zero in this way.

If the scope issue can be solved, maybe a pseudo function syntax would be possible that can also support escaping (just like format does). It is a good exercise for a junior developer to try. Maybe something for the "FPC unleashed" branch?

Might be one way.
I was actually leaning more toward "C-style macros", but that's another kettle of fish

[Bart]

What's wrong with

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

1. Writeln('Hello, '+Name+'! You''re '+IntToStr(Age)+' years old.');
2.  
3. {Needs Sysutils in Uses}
4. Writeln('Hello, '+Name+'! You''re '+Age.ToString+' years old.');

The IntToStr (and similar the .ToString) are superfluous. Write(Ln) can handle integers just fine, no need to convert them to string.

Bart

[Fibonacci]

@Fibonacci Can FreePascal support syntax like Python's f'string {variable}' or JavaScript's ${variable}for string variable interpolation? Make FreePascal better (great)! 

Unfortunately the forum doesn't send notifications when someone is mentioned in a post, so I'm only now reading this thread.


Good news: I already have this implemented. It's sitting in the feat-strinterp branch, waiting to be published (or not). It may be available in FPC Unleashed under the INTERPOLATEDSTRINGS modeswitch, or just unleashed mode. I just rebased it to the devel, so you can merge it yourself without conflicts and play with it

I don't publish everything I write - I'm not even sure if this feature is "worthy enough" to be included in FPC Unleashed. Either way, publishing a feature takes time - documentation, examples, explaining things to people, answering questions, potential bugfixes. And I'd rather write code than deal with people - could really use someone else on the "team" (since currently it's just me ).

Anyway, next to be published is the tuples feature. It's already in the devel branch on GitHub and available for testing. I'll be moving it to main soon and announcing it.


Back to interpolated strings - in FPC Unleashed the prefix is $, and it works like this:

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

1. var name := 'Fibonacci';
2. writeln($'Hello, I am {name}');
3.  
4. name := 'a cat';
5. writeln($'Hello, I am {name}');
6.  
7. for var i := 1 to 5 do writeln($'The value of i is {i}, i*10 is {i*10}');
8.  
9. var pi := 3.14;
10. writeln($'Pi is {pi}');
11. writeln($'Pi is {pi:0:2}');

Output:

Code: Text  [Select][+][-]

1. Hello, I am Fibonacci
2. Hello, I am a cat
3. The value of i is 1, i*10 is 10
4. The value of i is 2, i*10 is 20
5. The value of i is 3, i*10 is 30
6. The value of i is 4, i*10 is 40
7. The value of i is 5, i*10 is 50
8. Pi is 3.14000000000000010000
9. Pi is 3.14

Binary size on Win64: ~50 KB.

This is 100% implemented in the compiler - no Format(), no SysUtils in uses. It just works out of the box, adding nothing to the binary size.

[440bx]

could really use someone else on the "team" (since currently it's just me ).

Off topic:  I was under the impression that you and Warfley were the team.  Was that the wrong impression ?