Spaces are allowed here ?

[LV]

Object Pascal is a free-form language. However, conventions (recommendations) can be followed or ignored, even if the compiler skips it.

https://sourceforge.net/projects/object-pascal-style-guide/

[440bx]

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

1. if i&mod&7 = 0 then
2. ...
3.  

MarkMLl

I think the "&" should have been accepted as a regular identifier character with the restriction that it could only be used as the first character.  That would make "i&mod" and "mod&7" illegal (because in both cases the "&" would be considered as not being the first character.)

Unfortunately, the "&" is a just a scanner artifice, i.e., &anychars = anychars, which leads to strange situations because it is accepted in places other than identifiers (and keywords, which is what it's supposed to "nullify", i.e., "&for" <> keyword.)

[MarkMLl]

I think the "&" should have been accepted as a regular identifier character with the restriction that it could only be used as the first character.  That would make "i&mod" and "mod&7" illegal (because in both cases the "&" would be considered as not being the first character.)

Unfortunately, the "&" is a just a scanner artifice, i.e., &anychars = anychars, which leads to strange situations because it is accepted in places other than identifiers (and keywords, which is what it's supposed to "nullify", i.e., "&for" <> keyword.)

I was assuming in my example that it /was/ the first character, and focusing on the potential ambiguity in the numeric constant. That can obviously be resolved by looking at the character immediately after the &, but that's nasty particularly in the context of what's supposed to be a simple syntax.

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

1. if i+&10 = 0 then
2. ...
3.  

I'm very uncomfortable with the whole "& escapes reserved words" business. I've seen compilers that were deranged by leading or embedded predefineds hence abominations like reedfyle(), but allowing properly-delimited identifiers to be escaped like that... well, IMO it has no place in a language where the majority of users foam at the mouth whenever they see a C-style "\n" in discussion.

At the same time, this "spaces can be omitted" business rankles because when I've suggested that _ be allowed to indicate array or string concatenation (freeing + for vector operations) I've been told that _'s common use in variable and function names would mean that repurposing it would break too many things.

MarkMLl

[Thaddy]

Whitespace is not part of the language, it has no meaning, is ignored, so follow the rules and you will be safe. Has always been the case. Always.
See PascalDragon's reply.

It is not Python, i might add.

[Fibonacci]

[offtopic]@Thaddy: nice profile pic [/offtopic]

[MarkMLl]

Whitespace is not part of the language, it has no meaning, is ignored, so follow the rules and you will be safe. Has always been the case. Always.
See PascalDragon's reply.

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

1. i := jdivround(sin(x));
2.  
3. // Is not the same as
4.  
5. i := j div round(sin(x));
6.  

The presence of whitespace /does/ have significance, and PascalDragon has not commented in this thread.

MarkMLl

[tetrastes]

Whitespaces are ignored in fixed-form Fortran, so all that is the same:

Code: Fortran  [Select][+][-]

1.       complex*8 z0, z1
2.       complex*8z0,z1
3.       com   pl ex * 8z  0,z  1

Compilation begins with removal of spaces.

Sorry for offtopic.

[alpine]

The presence of whitespace /does/ have significance, and PascalDragon has not commented in this thread.

Of course it does, since it is not part of the Pascal lexemes (as well as other symbols) but it isn't a lexeme on its own - thus it is insignificant for the language seen as constructed from rules for ordering of the latter.

[TRon]

Just as you put spaces at the beginning of a line for indentation, they can also be between identifiers/operators, since they are not part of it:

Besides beating a dead horse (I can take it so don't worry)  you seem to be wanting to slaughter the cows and sheep as well 

/sarcasm on/ But you are right in that in my 40+ years dealing with Pascal I never imagined one could make use of whitespace. /sarcasm off/

You are missing the point about redefining the definition of a identifier, which was what I was referring to.

[Warfley]

Whitespaces are like comments "noise", meaning they are tokens for which there are matching rules in the Lexer, but these tokens do not get passed to the parser. Meaning that whitespaces are valid code tokens, so the FPC does not throw an invalid character error (as it does on Unicode chars right now), but also most importantly because whitespaces are not part of any other symbol it's used to separate symbols. But in theory you could also use comments for this

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

1. for{}I:=minindex{}to{}Maxindex{}do

[n7800]

/sarcasm on/ But you are right in that in my 40+ years dealing with Pascal I never imagined one could make use of whitespace. /sarcasm off/

{$SARCASM ON} If you had that much experience, you would have used sarcasm directives correctly... {$SARCASM OFF}

And yet I wrote to the author of the topic ))

Whitespace is not part of the language, it has no meaning, is ignored, so follow the rules and you will be safe. Has always been the case. Always.
See PascalDragon's reply.

The presence of whitespace /does/ have significance, and PascalDragon has not commented in this thread.

He is talking about his answer on the bug tracker.

[Paolo]

thaks to all for this intersting discussion.

Please note that I've never written this type of code (the one in my first post).
I got there by accident, mistyping a space and noticing that it works.

[Warfley]

There are good cases to write code like that. There is a pattern, I forgot the name, where methods return self, which allows chaining of method calls, an example would be a builder class:

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

1. MyObject := TMyBuilder.Create.AddObject(Prop1).AddObject(Prop2).AddObject(Prop3).BuildAndFinal;

Can be rewritten as

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

1. MyObject := TMyBuilder.Create
2.             .AddObject(Prop1)
3.             .AddObject(Prop2)
4.             .AddObject(Prop3)
5.             .BuildAndFinal;

Which makes it much easier to read

[Thaddy]

It is called Method chaining.
That's how KOL is built.