Musing about too many comment types in Pascal...

[Thaddy]

I don't see {$if 0}/{$ifend} yet. {$if 00} is true as per documentation, but {$if 0} is false and begins a comment, but with syntax highlighting active..

[AlanTheBeast]

Thread HIJACKING IN PROGRESS.

Arguing about the nonsense above when serious consideration to adding 'step' to the for loop statement should take precedence is a waste of time!

Adding "step" to the "for" loop isn't something I consider worth serious consideration.  Yes, it would make the loop a bit more obvious when that feature is needed but, it is rarely needed.   It's hard to approve of spending time adding a feature that is needed once in a blue moon.

I'd much rather see the compiler not considering an HWND assignable to an HMODULE assignable to an HPALETTE assignable to an HREGION assignable to an HBITMAP and so on.  That is much more useful and needed because there are quite a few functions that take parameters that if inadvertently reversed cause errors/bugs and the compiler is of no help whatsoever.  So much for "strong type" checking.

Your assertion that it is rarely used and not worth consideration may reflect your experience, but it does not reflect everyone's experience.  By far.

Why it is a "for loop" feature (by different names) in numerous languages from the old gods (Fortran, Basic) to the new (C, Python, Rust) and for that matter Modula-2 (Wirth having seen the error of his Pascal ways).

Not having it is a pain for those who need such.

Having it won't affect those who don't need/want it.

Code: ASM  [Select][+][-]

1. # Var i located in register w19
2. # [1215] for i := 0 to 14 do
3.         movz    w19,#65535
4.         .align 2
5. Lj503:
6.         add     w0,w19,#1
7.         uxth    w0,w0
8.         mov     w19,w0
9.  

Two items in the above code (ARM) would change (initial value (here: -1), and the step valus constant (here #1)). 

VERY efficient at run time, and surely no biggy to implement in the compiler.

*Yes, this is over simplified, but not that much.

[440bx]

Your assertion that it is rarely used and not worth consideration may reflect your experience, but it does not reflect everyone's experience.  By far.

I read a fair amount of code written by other programmers in other languages and I rarely see loops that have a step other than 1 or - 1.

That said, I invite you to provide examples of _common_ cases where such a feature (step) would be genuinely useful.   About 5 examples would be nice.

[ASerge]

Yeah... Drop your opinion on the comments

Let's look at this compiler directive:

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

1. {$WARN 5024 off : Parameter "$1" not used}

This is a directive, but also a comment. Convenient, yes. And this is what you propose to break?

[AlanTheBeast]

Your assertion that it is rarely used and not worth consideration may reflect your experience, but it does not reflect everyone's experience.  By far.

I read a fair amount of code written by other programmers in other languages and I rarely see loops that have a step other than 1 or - 1.

That said, I invite you to provide examples of _common_ cases where such a feature (step) would be genuinely useful.   About 5 examples would be nice.

Not going to waste time on 5 examples, but one that recently springs to mind:
(And while it os a recent test proc, I often sweep circles in increments of 5, 10 or 15 degrees depending on WTF I'm working on at the time).

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

1. Procedure TesTan;
2. VAR
3.         i : word;
4.         y : double;
5.         x: double;
6.         d2r:double;
7. BEGIN
8.         d2r := pi/180;
9.         for i := 16 to 20 do  //just what the fuch does this mean?
10.                 begin
11.                         y := i * 5;
12.                         x := y * d2r;
13.                         write (i:5,x:22:17);
14.                         x := tan(x);
15.                         writeln(y:8:1,x:25:5);
16.                 end;
17. END;
18.  

[Gustavo 'Gus' Carreno]

Hey ASerge,

Before I quote-answer: OOHHH GOODIE!! Been lazy to go find this one in particular. Cannot thank you enough for your answer!!

Let's look at this compiler directive:

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

1. {$WARN 5024 off : Parameter "$1" not used}

This is a directive, but also a comment. Convenient, yes. And this is what you propose to break?

I would prefer not to break anything, lets get that straight. Hence me dropping the suggestion to have { } only for directives!

I would prefer an enhancement of what we have:

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

1. ${
2.   MODE OBJFPC;
3.   H+;
4.   WARN 5024 off : Parameter "$1" not used;
5.   SWITCH THIS;
6.   SWITCH THAT;
7. }

We still would maintain the same directive's syntax. We would just have them neatly grouped at the top, for the global ones.
The per block, like the {$IFDEF}, would still be one liners, has they have to be:

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

1. ${IFDEF LINUX}
2. // Code for Linux
3. ${ENDIF}

Or, while we maintained the previous one, until it's deprecated, we could chose the one liners to be in the old syntax...

Cheers,
Gus

[Gustavo 'Gus' Carreno]

Hey Alan,

Can I, very politely, ask you to cease the topic hijack?

You have made your point. The rest is just "Old Man Shakes Fist At The Moon" territory.
And, if I may, you DID create a thread to have this discussed.

Do you see me going to your thread and hijacking it with the kind of nonsense I'm trying here? No, amirite?!

So, please, please, with sugar on top: Could you shift gears and continue your plea on the thread you created for said plea?
I would greatly appreciate if you did.

Cheers,
Gus

[Thaddy]

Gus, that is why I added the, on subject,:

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

1. {$if 0}
2.   mode objfpc
3.   H+
4.   switch functionreferences
5.   switch sumtypes
6. {$ifend}

Which is a comment....
You can always ask for implementation of such body later.

[Gustavo 'Gus' Carreno]

Hey Thaddy,

Gus, that is why I added the, on subject,:

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

1. {$if 0}
2.   mode objfpc
3.   H+
4.   switch functionreferences
5.   switch sumtypes
6. {$ifend}

Which is a comment....
You can always ask for implementation of such body later.

Ok... I looked at this and it didn't make sense, sorry.
On the Discord, this was actually mentioned, and I thought it would be quite the nice trick to play with dual language compiling... If I ever sussed how to ignore the {$if 0} and {$endif} on the other language.

But now I'm utterly confused because you terminate with {$ifend}.
Then you say this is a comment, which makes sense since 0 evaluates to false and this means it will never be compiled.
And then you say: "You can always ask for implementation of such body later.", and this is the most confusing part:
Is this construct with {$endif} an existing thing?
Are you saying that the construct with {$ifend} is what I need ask to implement?

Nevertheless, while I do agree that it is a neat trick with current syntax, I'm still attached to the more visually balanced ${  } block.
Sorry, I may be coming across a tad pedantic, but this like a kid in a candy shop... I want it like I want it.
Even if ultimately, it's just a pipe dream and the powers that be will shoot me down and I descend to the Earth as a ball of thunder and fire

Cheers,
Gus

[Thaddy]

@Gustavo 'Gus' Carreno

Actually, that has directly to do with Delphi:

First they thought it would be a good idea to terminate {$IFDEF} with {$ENDIF} and then they had the brilliant idea to have an {$IF X} where X could be an expression. Fair enough, welcome addition.
So, they implemented the idea by implementing {$IF X} and then closed that with {$IFEND}.
Which is the logical way to distinguish between {$IFDEF}/{$ENDIF} and {$IF X}/{$IFEND}...

Then, after all the sane computer scientists left the building, one stupid brain came up with a parser adaptation that allowed {$ENDIF} after {$IF X}??? thus eliminating the distinction between the ending for {$IFDEF} and {$IF X}.... (BIG WTF    , they are supposed to have a degree in CS)
While this seems convenient, that mutilates their meaning, which is quite different.

Freepascal decided to follow Delphi and so after {$IF}, {$ENDIF} is also allowed and, even worse, they (both Delphi and FPC), deprecated {$IFEND}, which makes no sense to me so I always close {$IF X} with {$IFEND} and always close {$IFDEF} with {$ENDIF}...
But for {$IF}, both are allowed, alas.

A history of good design vs. bad design after the initiators left the building.

I don't know if I have to be disappointed, or just plainly sad.

So you can do everything you want, but please close {$IF X} with {$IFEND}?
It will save you making mistakes and make the blocks immediately obvious.

[Gustavo 'Gus' Carreno]

Hey Thaddy,

@Gustavo 'Gus' Carreno

Actually, that has directly to do with Delphi:

First they thought it would be a good idea to terminate {$IFDEF} with {$ENDIF} and then they had the brilliant idea to have an {$IF X} where X could be an expression. Fair enough, welcome addition.
So, they implemented the idea by implementing {$IF X} and then closed that with {$IFEND}.
Which is the logical way to distinguish between {$IFDEF}/{$ENDIF} and {$IF X}/{$IFEND}...

Then, after all the sane computer scientists ran away, one stupid brain came up with a parser adaption that allowed {$ENDIF} after {$IF X}??? thus eliminating the distinction between the ending for {$IFDEF} and {$IF X}.... (BIG WTF    , they are supposed to have a degree in CS)
While this seems convenient, that mutilates their meaning, which are quite different.

Freepascal decided to follow Delphi and so after {$IF}, {$ENDIF} is also allowed and, even worse, they (both Delphi and FPC), deprecated {$IFEND}, which makes no sence to me so I always close {$IF X} with {$IFEND} and always close {$IFDEF} with {$ENDIF}...
But for {$IF}, both are allowed, alas.

A history of good design vs. bad design after the initiators left the building.

I love me some juicy history facts!! Thank you so much for this Thaddy !!
And that clarifies my doubt. Sure enough it was, as per the usual, based on another of my blind spots on all things Object Pascal.

As of late, even with these semi-jesty threads, the knowledge keeps pouring in.
Maybe I should make this a habit... To the absolute chagrin of the core team

I don't know if I have to be disappointed, or just plainly sad.

Yeah, same

So you can do everything you want, but please close {$IF X} with {$IFEND}?
It will save you making mistakes and make the blocks immediately obvious.

Will do boss!!
That makes sense and disambiguates things which is always the best!!

I'm a fierce proponent of otherwise at the end of a case, not an else. Too much ambiguity, me thunks!!

Cheers,
Gus

[AlanTheBeast]

Hey Alan,

Can I, very politely, ask you to cease the topic hijack?

You have made your point. The rest is just "Old Man Shakes Fist At The Moon" territory.
And, if I may, you DID create a thread to have this discussed.

Do you see me going to your thread and hijacking it with the kind of nonsense I'm trying here? No, amirite?!

So, please, please, with sugar on top: Could you shift gears and continue your plea on the thread you created for said plea?
I would greatly appreciate if you did.

Cheers,
Gus

Already moved on - but did answer one question as challenged.

[AlanTheBeast]

I'm a fierce proponent of otherwise at the end of a case, not an else. Too much ambiguity, me thunks!!

Else is fine with me.

But, EndCase; would be better than end; for case statements in my opinion.

For that matter I style them:       end{case};

And nested Case go:

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

1. Case job of
2.   CASE boo of
3.     case gee of
4.     end{Case job};
5.    END {CASE boo};
6. end{Case gee};
7.  

[Gustavo 'Gus' Carreno]

Hey Alan,

Already moved on - but did answer one question as challenged.

Good that you moved one. Many thanks for that.

And I do agree that a direct challenge, that needs a direct answer. I was more worried that you'd be fixated here and not on your thread.
I think you did good, and I'm grateful this did not devolve into a Miss J. situation ( And if you don't know, be glad for the bliss of ignorance !! )

Cheers,
Gus

[Gustavo 'Gus' Carreno]

Hey Alan,

Else is fine with me.

I'm all good with options. That means we have choices to express ourselves the way we want.
I'm expressing myself with the otherwise. I'm all good with you expressing yourself with the else!!
What do they say? Ahh, yes... Kumbaya

For that matter I style them:       end{case};

And nested Case go:

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

1. Case job of
2.   CASE boo of
3.     case gee of
4.     end{Case job};
5.    END {CASE boo};
6. end{Case gee};
7.  

I like your style. Again, a good way of expressing that inner self !! ( Though 2 are swapped, but hey, I get your drift !! )
Sure, more typing needed, but heck, Pascal is verbose, so lets embrace the shite out of it

Cheers,
Gus