Str declaration

[Thaddy]

The str procedure was defined by Niklaus Wirth as part of the original Pascal language. It’s been a fundamental part of Pascal since its inception.
What is different from FreePascal, though, that you can override it, but that is a fallacy.

If you can find any counter claims, please let me know....( you can't )

[Kays]

str belongs to the early pascal family, it is not related to any dialect.

I could not find it in Wirth’s 1973 Revised Report. Maybe you have some magical capabilities of reading between the lines. GPC claims it was a UCSD Pascal extension in origin that was generalized by BP. This info is what I incorporated into the wiki.

[MarkMLl]

I could not find it in Wirth’s 1973 Revised Report. Maybe you have some magical capabilities of reading between the lines. GPC claims it was a UCSD Pascal extension in origin that was generalized by BP. This info is what I incorporated into the wiki.

Note that that's a very early edition, predating Kathleen Jensen's involvement: on p50 of the PDF it shows /* */ as digraphs for { } which I think Wirth abandoned in favour of (* *) because he realised that other languages were using them. He was very much trying to mark out his own turf, hence Pascal's  program layout etc. which couldn't be mechanically-reconciled with ALGOL and derivatives (while being unable or at least reluctant to tinker with the recursive-ascent parser that he'd inherited from ALGOL-W).

Without having a copy of the "gold standard" J&W ** in front of me, I'm happy enough to accept Thaddy's assertion that Str() was in early (i.e. pre-UCSD/Borland) implementations of the language. My *ONLY* point is that the compiler isn't happy overloading it, followed by the fact that if it were a reserved word I'd expect it to be documented as such... or thrown out by the compiler, which instead get unhappy the first time it sees an attempt to call Str() elsewhere.

I'm not inclined to make much of it. But as for the other party... https://www.youtube.com/watch?v=lzmhZQVna8E

:-)

MarkMLl

** http://pascal.hansotten.com/uploads/books/Pascal_User_Manual_and_Report_Second_Edition.pdf (1974) doesn't have Str(), and discusses Write() etc. as special cases classified as "standard procedures". However at this point I think it's fair to consider that these early versions omit String as a fundamental type, hence Str() as a function returning a string cannot have been a Wirthism: it must originate in some other early implementation i.e. probably UCSD or Turbo Pascal.

[Thaddy]

It predates my starting point with Pascal indeed, which was UCSD on Apple.
Both chr() and str(). The two belong together.
It is rather fultile to argue otherwise.

[ASerge]

str is a reserved word and a compiler intrinsic.

First false, second true.
It possible to declare a procedure or function named Str, but cannot use a colon as a parameter separator.

[MarkMLl]

It possible to declare a procedure or function named Str, but cannot use a colon as a parameter separator.

The "problem" is that irrespective of parameter type the newly-defined one appears to be used in place of the intrinsic, so (a) colons used anywhere in the program will cause a problem and (b) faulty type assumptions will almost certainly cause a problem.

The reference manual should somewhere document Write(), WriteLn(), Str() and WriteStr() as special cases: possibly not reserved words but definitely not as ordinary procedures amenable to redefinition.

MarkMLl

[Kays]

[…] The reference manual should somewhere document Write(), WriteLn(), Str() and WriteStr() as special cases: possibly not reserved words but definitely not as ordinary procedures amenable to redefinition. […]

In FPC you can always access the built‑in procedures by specifying an FQI, say system.writeLn despite a custom writeLn declared in the current scope.

[MarkMLl]

[…] The reference manual should somewhere document Write(), WriteLn(), Str() and WriteStr() as special cases: possibly not reserved words but definitely not as ordinary procedures amenable to redefinition. […]

In FPC you can always access the built‑in procedures by specifying an FQI, say system.writeLn despite a custom writeLn declared in the current scope.

I know. But since that group of intrinsics is fundamentally "deeply magical" at the system level I'd have expected them to be parsed and rewritten early: and that's particularly the case if the point of use contains a colon.

Quite frankly, I'm deeply committed to backward compatibility and respecting the spirit of a language but if it were my choice I'd have deprecated that special parameter notation decades ago. Modern Pascal supports parameter lists as used in e.g. Format(), and it has partial support for literal tuples of which later elements can be omitted, and it should be possible to replace e.g.

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

1.   WriteLn('Pi: ', 3.1416:6:4);
2.  

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

1.   WriteLn(['Pi: ', (3.1416, 6, 4)]);
2.  

without causing too much grief. And Wirth apparently agreed in that he axed them from Modula-2, unfortunately he also axed Pascal's string type which was one of the language's major selling points.

MarkMLl

[PascalDragon]

Both chr() and str(). The two belong together.
It is rather fultile to argue otherwise.

Neither Chr nor Str are reserved words.

The reference manual should somewhere document Write(), WriteLn(), Str() and WriteStr() as special cases: possibly not reserved words but definitely not as ordinary procedures amenable to redefinition.

Those are just ordinary identifiers that can be redefined as one wants. Same with e.g. Break and Exit. That they have some magic ability is no problem, because one can just use System.XXX to still access them if necessary.

[d2010]

Hi!
According to docs, the Str procedure is declared like this:

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

1. procedure Str(var X: TNumericType[:NumPlaces[:Decimals]];var S: String)
2.  

Can I declare a procedure like this? If so, how can I use inside the procedure the :NumPlaces and :Decimals values?

Thak you.

In Borland7Delphi  I found these..

Code: [Select]

Procedure myStr(x:Integer;Numplaces:word;Decimals:word Var destVar:string);overload;
Procedure myStr(x:Integer;Numplaces:word; Var destVar:string);overload;
Procedure myStr(x:Integer;Var destVar:string);overload;
Hint1=Where you use one type X:integer; I think overload work very good,
Hint2=You change definition of myStr like these bellow; moving all fix types at begin of (..

Code: [Select]

Procedure myStr(Var destvar:string;x:Integer;Numplaces,Decimals:word;);overload;
Procedure myStr(Var destvar:string;x:Integer;Numplaces:word);overload;
Procedure myStr(Var destvar:string;x:Integer);overload;
Hint3=I do not have experince with overload; inside Delphi & Pascal.
Question= The TNumericType exists inside LazarusForumPascal?

[TRon]

Hint1=Where you use one type X:integer; I think overload work very good,
Hint2=You change definition of myStr like these bellow; moving all fix types at begin of (..

In that case you can just as well use Mark's suggestion and use format, e.g.

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

1. procedure printf(s: string; const fmt: array of const);
2. begin
3.   write(format(s, fmt));
4. end;
5.  

Question= The TNumericType exists inside LazarusForumPascal?

Not for the end-user.

It is used in the intrinsincs as mentioned earlier and done so for a reason. Implementations such as write, str etc are able to catch issues at compile time while an implementation such as format is only able to catch errors at runtime.

[MarkMLl]

The reference manual should somewhere document Write(), WriteLn(), Str() and WriteStr() as special cases: possibly not reserved words but definitely not as ordinary procedures amenable to redefinition.

Those are just ordinary identifiers that can be redefined as one wants. Same with e.g. Break and Exit. That they have some magic ability is no problem, because one can just use System.XXX to still access them if necessary.

Please note that I am not claiming this is a bug or something that demands attention, but:

I agree that Break and Exit can be redefined. However the "preprocessing" of the Str() parameters makes Str() etc. special:

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

1. program test2;
2.  
3. type
4.   tExpansionState= (esUnexpanded, esExpanded, esWasExpanded, esInvalidated);
5.  
6.  
7. procedure str(es: tExpansionState; var s: string);
8.  
9. begin
10.   System.Str(es, s)
11. end;
12.  
13.  
14. var
15.   scratch: string;
16.  
17. begin
18.   { System. } Str(1.0:6:4, scratch);
19.  
20. end.
21.  

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

1. $ fpc test2
2. Free Pascal Compiler version 3.2.2 [2023/09/04] for x86_64
3. Copyright (c) 1993-2021 by Florian Klaempfl and others
4. Target OS: Linux for x86-64
5. Compiling test2.pas
6. test2.pas(18,22) Fatal: Syntax error, ")" expected but ":" found
7. Fatal: Compilation aborted
8. Error: /usr/local/bin/ppcx64 returned an error exitcode
9.  

The "principle of least surprise" suggests that Str() in the body of the program, applied to a literal number, should not be distracted by the fact that str() has been overridden locally for a tExpansionState. But it /is/ being led astray, and it's erroneously reporting that it expects ) when in actual fact it should be expecting , irrespective of which definition of Str() it's looking at.

MarkMLl