Str declaration

[ricardo_sdl]

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.

[MarkMLl]

No.

MarkMLl

[silvercoder70]

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.

Here is a slightly longer answer...

https://www.freepascal.org/docs-html/rtl/system/str.html
https://wiki.freepascal.org/Str

however, you still cannot. My question would be... what are you trying to achieve?

Tim

[MarkMLl]

Historical background.

When Wirth (hurriedly) defined Pascal, it was still common for system operations such as input/output to be embedded in the compiler. IBM had separately-linkable libraries, but they were rather the exception with everybody else using include files; the idea of enforced cross-module parameter checking etc. which implied a uniform procedure/function declaration format was still in the future.

As such, languages including FORTRAN, (some) ALGOLs and (later) C and its derivatives tended to use separate format or picture declarations, with some level of ambiguity as to whether they were parsed at compilation or execution time.

In order to avoid the parsing complexity, particularly where a format declaration was separate from the one or more places where it was used, Wirth took the relatively simple way out: annotate each parameter with minimal information regarding its format. That also made it relatively easy to define that field widths etc. should be computed at runtime, rather than being predefined.

Wirth dropped this notation for Modula-2, and I'm not aware of any Pascal implementation that generalised it to be user-accessible.

MarkMLl

[cdbc]

Hi
As @MarkMLl said, no, 'cause it's an 'Intrinsic' proc in the compiler, a better word for it would be "Magic". 
You can however, emulate this behavior with an overloaded procedure, i.e.: *you* write an overloaded proc, for *every* possible type you'd come across!
Then leave it up to the compiler to pick the right one at runtime 
edit: Nice explanation Mark... You were faster.
Regards Benny

[MarkMLl]

You can however, emulate this behavior with an overloaded procedure, i.e.: *you* write an overloaded proc, for *every* possible type you'd come across!
Then leave it up to the compiler to pick the right one at runtime 

But that still wouldn't handle : as the parameter separator.

MarkMLl

[440bx]

You can however, emulate this behavior with an overloaded procedure, i.e.: *you* write an overloaded proc, for *every* possible type you'd come across!
Then leave it up to the compiler to pick the right one at runtime 

That method works reasonably well when parameters are required but when values are optional and worse, separated by semicolons, overloading doesn't "map" that functionality very well.

MarkMLI pointed that out too while I was typing this post.

[cdbc]

Hi
I think it was Mick Jagger, who said "You can't always get what you want" 
Regards Benny

[ricardo_sdl]

Thank you all for the answers! I wasn't trying to achieve something, just curiosity about the different procedure declaration and I wondered if I could do the same with my code. Nice history lessons here!

[MarkMLl]

Looked at obliquely, in some of my own scripting stuff I've experimented with a Smalltalk-based calling notation.

I'd rather not try to dig out any robust examples, because one of my goals was to define the absolute minimum of reserved characters and along the way I painted myself into a corner (and because it was live code decided to live with it). But basically everything was uniform and had parallels with the way FPC initialises record constants: a parameter was named, followed by a colon, and that was followed by a value

Code: [Select]

print(to: stdout value: fred);

or

Code: [Select]

print(to: stdout value: fred format: something);

or potentially

Code: [Select]

print(to: stdout format: something value: fred);


and so on. If a default was to be used then a - was used as a placeholder:

Code: [Select]

print(to-value: fred);

and so on. However there's no easy way to convert this back to usable Pascal without a custom parser.

MarkMLl

[MarkMLl]

You can however, emulate this behavior with an overloaded procedure, i.e.: *you* write an overloaded proc, for *every* possible type you'd come across!
Then leave it up to the compiler to pick the right one at runtime 

But that still wouldn't handle : as the parameter separator.

Also it appears that since Str() (hence Write() etc.) is "magic" with special handling by the compiler, those functions cannot be overloaded.

MarkMLl

[Thaddy]

str is a reserved word and a compiler intrinsic. just read all other answers.

[MarkMLl]

str is a reserved word and a compiler intrinsic. just read all other answers.

I felt it worth making the point in the context of OP, having been casually caught by it yesterday.

However you might care to point it out for me in https://www.freepascal.org/docs-html/current/ref/refse3.html#refsu3.html since I'm blowed if I can see it.

MarkMLl

[Thaddy]

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

[MarkMLl]

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

So do begin, end and so on. Str is not documented as a reserved word.

MarkMLl