Hi,
I 've come across a really strange (bug?) in Oxygene, which allows me to write:
writeln(100 -- 2) // prints 102
aswell as:
writeln(100 ++ 2) // prints 102
testcase needed?
–Shpend
Perfectly valid. 100 minus -2 equals 102.
ah ok, yes that ofc makes sense ^^
I didnt had that in mind in that time, included, that I would write such things more like: 100 - (-2)
but ok, and why allowing the last?
Strange, you always complain when something is not standard Pascal. And now, when something is 100% standard Pascal, worked this way in the very first version Niklaus Wirth wrote, you seem to complain too. 
Seems really hard to find out what you really want 
Pascal allows to have a sign in front of a number (+ or -). And there are are operators which accept two numbers, such as +, -, *, etc. => it’s perfectly legal to write:
- 1 ++ 2
- 1 - - 2
- 1 + - 2
- 1 -+ 2
I dont know why, when I ask for some concepts or some ways the RO guys implement stuff, it is often interpreted as complaining. I am not complaining, i am just wondering, because I have forgotten some of Pascals syntax structures and therefor the question.
yes, again, makes sense, because its a relative strong math-syntactic-language
Thx for clarity!
Like me, lot’s of the guys in this forum are not native English speakers. So, complain is probably not the right word for it 
And by the way, don’t take me too serious. My original answer was meant a bit as a joke, but yeah, jokes don’t translate…
2 Likes
Yikes. I know whitespace is not considered significant in Pascal, but this does raise some questions about when it is and is not considered such. Whilst it can sort of be rationalised when it comes to the spacing/positioning of a sign operator vs an arithmetic operator in the same expression, what is far more befuddling (to me) is something like this:
writeLn( 10 0 + 1 2 ); // 112
You could of course argue “what else is the compiler supposed to make of this?”, but I would expect that the compiler would point out that what it’s been given appears to make no sense. Are there operators missing between the numeric digits or did I just screw up the formatting of my operands ? Both are equally plausible.
Consistency further crumbles when you explore other variations, e.g:
var a := 1;
var b := 2;
var ab := 3;
writeLn( a b ); // Does not compile
Why does the compiler not disregard the whitespace between the identifiers and treat them as if the intervening whitespace did not exist, as it does with numeric literals ? Or, conversely, why is whitespace not significant between numerics if it is significant between identifiers ?
Or, returning to more straightforward numeric values:
writeLn( 10 2 ); // 102
writeLn( 1.0 2 ); // 1.02
writeLn( 1 0.2 ); // 10.2
writeLn( 10 .2 ); // does not compile
This may well be within the strict rules of the language, but that doesn’t make it any more sensible, imho.
This is the feature for more readable large numbers we (and most other languages) added a few years back, you can abuse it, but the idea is to use it to space by thousands: 1 000 000)
That would sorta make sense if it were limited to allowing/accepting a single space as a grouping character but the rule appears to be “any whitespace inmixed with numerals is non-significant”. If limited to only a sigle space at least then if you had multiple spaces the compiler would ask you to clarify whether you had intended to group (reduce to a single space) or had inadvertently missed an intended operator.
I have to ask: If it was for grouping, why choose whitespace in this way rather than simply comma ? (yes yes I know that comma-grouping is cultural, not universal, but so is the use of period for decimal point - or indeed spaces for grouping 
).
Well, in Pascal whitespaces is whitespace. one space is as good as 500 spaces are, and vice versa.
how would that work?
String.Format(" {0} {1} {2}", 5,000, 8,000, 10,000);
would be rather impossible…
Ooops. All I can say here is that I posted that question before having had my coffee. 
Of course that then raises an interesting discussion as to why we need to comma separate args if whitespace is otherwise significant.
i.e. if whitespace is insignificant then
WriteLn ( a b );
Should be exactly equivalent to:
WriteLn(ab); // where 'ab' is a valid identifier in scope
But if it is significant, then comma separation of args is/could/should be redundant and so comma’s could then be used for number grouping.
Caveat: I’ve now had my coffee, but I’ve still not spent a huge amount of time thinking about all the edge cases (and I’m not suggesting that Oxygene be changed in this way, just idly speculating about the rules we adopt in our languages generally).
No. no space it not equivalent to any space. But if there is any space, at all the the size of it is insignificant (1, 100, tabs, line-breaks, mixed toghether, etc, they all collapse to a single space as far as tghe compiler knows or cares).
Of course that’s outside of string literals, to nip that rathole in the butt before it‘s brought up
Except line-breaks do not “collapse” if part of a numeric literal*, otherwise where space has collapsed to a single space in a numeric literal - and only in a numeric literal - it then appears (as a result of the compiler handling this as a special case in numeric literals) to disappear entirely.
-
:
const OK = 1 0;
const NOT_OK= 1 // ERR: ‘semi-colon expected’
0;
We’ll have to agree to disagree on this I think, but this strikes me as an odd choice to have made for what must be a very small set of scenarios involving “cumbersome” numeric literals.
It might have been clearer if the rule for numeric literals had been extended to allow for 1 - and only 1 - space to separate arbitrary groups of digits (including decimal point and all other elemental chars in a numeric literal) but conflating this with allowing (a subset of) arbitrary whitespace to be introduced and then treating that whitespace as collapsing to a single space and then “dissolving” that single space when occurring between numerics … seems a bit … messy. imho.
But, like I say - agreeable to disagreeing.