Recent

Author Topic: Please make your language more freedom  (Read 37042 times)

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Please make your language more freedom
« Reply #60 on: June 23, 2018, 05:50:11 pm »
neither does it support:
Code: Pascal  [Select][+][-]
  1.   if condition then begin
  2.     a:= 1;
  3.     DoSomethingWith(a);
  4.   end;
  5.   // a may be undefined... And yet you can access it
  6.  

FPC supports while <condition> do..
Code: Pascal  [Select][+][-]
  1. {$ifdef fpc}{$mode delphi}{$H+}{$endif}
  2. begin
  3.   while true do
  4.   begin
  5.     //
  6.   end;  
  7. end.

Specialize a type, not a var.

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Please make your language more freedom
« Reply #61 on: June 23, 2018, 08:26:58 pm »
I don't think that is what @Martin_fr was referring to.

 he is making the statement that declaring "A" variable on the fly and keeping it in the loop scope only
isn't supported.

 But I still like the idea of the for loop declaring the variable within the loop control setup, not inside the
loop block.
 
 I Think it was MS C that allowed me to do that for a "FOR" control and made it go out of scope when you
left the loop block, just a temp variable.

 For name:Type := StartValue to EndValue  Do... or begin.. ,end;
etc
 In this context you really don't even need a variable declared in the normal section, the compiler can simply
create a background variable for you and with no TYPE specified it would generate a integer;

 As for allowing this behavior anywhere else I don't agree with how C or others do this, just create variables on the fly
in the code base is unorganized and leads to hard to read code.




The only true wisdom is knowing you know nothing

mercurhyo

  • Full Member
  • ***
  • Posts: 242
Re: Please make your language more freedom
« Reply #62 on: June 23, 2018, 09:03:53 pm »
I don't think that is what @Martin_fr was referring to.

 he is making the statement that declaring "A" variable on the fly and keeping it in the loop scope only
isn't supported.

 But I still like the idea of the for loop declaring the variable within the loop control setup, not inside the
loop block.
 
 I Think it was MS C that allowed me to do that for a "FOR" control and made it go out of scope when you
left the loop block, just a temp variable.

 For name:Type := StartValue to EndValue  Do... or begin.. ,end;
etc
 In this context you really don't even need a variable declared in the normal section, the compiler can simply
create a background variable for you and with no TYPE specified it would generate a integer;

 As for allowing this behavior anywhere else I don't agree with how C or others do this, just create variables on the fly
in the code base is unorganized and leads to hard to read code.
echo echo echo...  :D
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Please make your language more freedom
« Reply #63 on: June 23, 2018, 10:20:31 pm »
Anyway if such idiocy was introduced to FPC, I am going back to Forth, or a HP57. >:D Or make Russia win the world cup...
Free speech for the dumb. https://www.youtube.com/watch?v=4GzUh4PJVx8
(And no.. Danes or trumpians, they are from England...) Brexetiers, trumpians and others need not reply to facts. Real facts.
(Although I would not mind a final between Denmark and Belgium)
If you can understand what I mean you are:
1. A programmer
2. Well educated programmer
3. Less likely to make mistakes outside of programming
4. Either you have no feet.(left, maybe both left..).. or you will never ever shoot yourself in the foot (again).

See the relevance?
« Last Edit: June 23, 2018, 10:50:16 pm by Thaddy »
Specialize a type, not a var.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #64 on: June 23, 2018, 10:58:09 pm »
As for allowing this behavior anywhere else I don't agree with how C or others do this, just create variables on the fly
in the code base is unorganized and leads to hard to read code.
echo echo echo...  :D

And that is my point, if this (declaring variables anywhere) is NOT good for other control blocks (like "if" or any other), then what makes "for" so special?

I do agree: There should be a warning about an uninitialized variable, if the variable is used after for, without being initialized again.

But just that it can be uninitialized is no reason for the "declare it special for the for loop" (or even any other block).
Even in languages that allow declarations anywhere, the problem of variables not being initialised does exist. So nothing to be gained.

 

mercurhyo

  • Full Member
  • ***
  • Posts: 242
Re: Please make your language more freedom
« Reply #65 on: June 23, 2018, 11:35:05 pm »
huh!?
introducing improvements does not mean "force to use, knife under neck" afaik I can still program in pure pascal, I mean TP like; all improvements after Object down

So, introducing new concepts would not bother oldies stuck around 1870 years' rules, as long as their old fashioned sources still work the right way with no change. Ever heard about "backward compatibility"?

the concept I suggested has multiple advantages (comprising avoiding 4 pages discussing long time issue over variables values on loops exits ha ha ha) and is not a forced plan. people used to declare vars on local stack and using old mode loops could continue without change! Transparently!
I however BET that if my concept (jamie delivered almost same) is adopted as enhancement, a majority of programmers are going to use that optional syntax
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #66 on: June 24, 2018, 12:31:03 am »
introducing improvements does not mean "force to use, knife under neck" afaik I can still program in pure pascal, I mean TP like; all improvements after Object down

So, introducing new concepts would not bother oldies stuck around 1870 years' rules, as long as their old fashioned sources still work the right way with no change. Ever heard about "backward compatibility"?

Doesn't really answer my question: why "for" but not "if"?
That of course is, assuming we agreed above that it was for "for" only, and not for "if".

As for your statement, which is a repeats:
No, it is "force to use". Because it will appear in public components that will have to be used. Or worse, it will appear in the rtl. The alternative is, that it will reduce the available libraries, it will make important security update unusable, ....

Variables declared ahead of the procedure (or the breakage of this) is not a feature. It is changing the fundamental design of the language.

<sarcasm>
With your argument in mind, I could also say that a modeswitch could be added, that makes {} tokens for begin/end (and (**) can be used for comments). It would be just optional so no harm.
And "*" or "->" could be used for pointer deref...
</sarcasm>

But again, even if we do not ask: why "for" but not "if"?
The question still stands: How does it help against uninitialized variables? As I said, you have uninitialized variables in c, or javascript too.

For the for loop that problem can be fixed, by having fpc issuing a warning (you can tell fpc to treat warnings as errors, so then it really will stop the issue: -Sew )


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #67 on: June 24, 2018, 12:39:02 am »
And to add, it would create new issues:

Code: Pascal  [Select][+][-]
  1. procedure foo;
  2. var i: integer;
  3. begin
  4.   for var i: integer := 1 to 9 do
  5.  
This can obviously not be allowed. You must not end up having 2 "i" in the scope. (If you did, mayhem will not wait to happen)

So you could not use a variable for the "for" that already is declared.

But that also means, that in the opposite case, if I need to introduce a new variable for a procedure, I would need to search the entire procedure body, to make sure it isnt used (while today, I can just look at the "var" section, so much easier.)

And IIRC it was stated the new feature would also help if you have really long procedures (which I think is a bad idea anyway). In that case searching the whole body becomes even worse.

So clearly this would be a step in the wrong direction.

lainz

  • Hero Member
  • *****
  • Posts: 4460
    • https://lainz.github.io/
Re: Please make your language more freedom
« Reply #68 on: June 24, 2018, 12:47:25 am »
The other day I was trying to change the value of i inside a for loop, and get that can't be done when compiling. Good =) Let's use a while loop instead.

As well I want that warning, trying to use the value of i when I exit, break, exception a for loop.

One can asume the value of i, and that's not good, since I've lost real time debugging a code that reuses an i of a loop, thinking that the value it should have is the one I think, and of course it was not the real one. And I'm talking of Java, not Pascal. The problem can come in any language, but if we can have a clue on what we're doing wrong is very welcome.

And about changing the Language. I know people (I'm one) that's currently developing for Delphi and Lazarus at the same time. Having compatibility between them is good, so I can reuse code from one to the other. And that is possible, I made a library that works in both worlds reusing most of the code, and third party libraries as well.

The thing is to write better code, an extra i declared in the var section will not make you less happy! In fact you had in control everything is used in the same *unique* scope (thanks for that!, really I lost real time debugging scope things in JavaScript as pointed, is a real problem!).

As pointed by others, divide an conquer (split into several functions if you don't want a lot of vars in the same place), or even create functions inside functions, that is good as well.

Edit: fix typo
« Last Edit: June 24, 2018, 01:05:07 am by lainz »

mercurhyo

  • Full Member
  • ***
  • Posts: 242
Re: Please make your language more freedom
« Reply #69 on: June 24, 2018, 01:16:29 am »


Doesn't really answer my question: why "for" but not "if"?
That of course is, assuming we agreed above that it was for "for" only, and not for "if".

As for your statement, which is a repeats:
No, it is "force to use". Because it will appear in public components that will have to be used. Or worse, it will appear in the rtl. The alternative is, that it will reduce the available libraries, it will make important security update unusable, ....

Variables declared ahead of the procedure (or the breakage of this) is not a feature. It is changing the fundamental design of the language.

<sarcasm>
With your argument in mind, I could also say that a modeswitch could be added, that makes {} tokens for begin/end (and (**) can be used for comments). It would be just optional so no harm.
And "*" or "->" could be used for pointer deref...
</sarcasm>

But again, even if we do not ask: why "for" but not "if"?
The question still stands: How does it help against uninitialized variables? As I said, you have uninitialized variables in c, or javascript too.

For the for loop that problem can be fixed, by having fpc issuing a warning (you can tell fpc to treat warnings as errors, so then it really will stop the issue: -Sew )

strange..
Ok I was absent for years on this forum, can you please point me the flaming topic where people were angry and mad at generics? thank you!
because template class<curlybrackets> does not seem to bother becoming generic class<fuckedupbrackets>

Ok... I mute! say hello for me to all stuck minded people around local loops & implicit iterators.
Thanks again, good luck
« Last Edit: June 24, 2018, 01:18:38 am by mercurhyo »
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

jamie

  • Hero Member
  • *****
  • Posts: 6090
Re: Please make your language more freedom
« Reply #70 on: June 24, 2018, 02:14:39 am »
@martin_Fr:

  the variable of course could be flagged as duplicate which should be in such cases if there are two in the
procedure body, it would only make sense.

 But the fact remains that the FOR loop variable in pascal is not to be used after the loop or should I say
value depended on, because its not in the language structure of pascal to do so.

 So it would only make sense to create a local variable for the FOR statement where it is only seen within
the scope of the loop and any nested loops of course because at that position those variables are still valid.

 This would stop those from trying to use the value of the loop when it exits and make code a little more reliable
between compiler updates. Of course coders could still use the current method, too.

 But to create variables in the Code body anywhere on the fly crazy talk.

 I seem to remember some C source code I looked at once where it reused the same variable  in a body of
code but with a different type, in other words, it would redeclare the variable as a different type mid stream, we sure
do not want to follow those steps!



The only true wisdom is knowing you know nothing

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #71 on: June 24, 2018, 02:59:23 am »
@jamie:

1) The reason (that I get from this thread) for not using the loop variable after the loop, is because it is uninitialized (except "break", but let's ignore...)

But then the variable can still be used for other purposes. If I have many 1 liner loops, I reuse the var, if some of them are "while" loops, I still reuse the var. If I used something generic, like "i" as var name, I may use it for any other short lived tasked a variable could fulfil in that function. All fine as long as I initialize it for each purpose.

What makes the uninitialized var after a loop so different to other uninitialized var?

(no one has yet answered this)

Again: If the compiler had a warning for this (which it really should have), then -Sew would solve the entire issue. Your compilation would fail, if you tried to get the value after a loop. And it would work for all uninitialized var.

2)
Quote
  the variable of course could be flagged as duplicate
Yes, what I implied before. And then each time you want to add a "regular" var (in the var section), then you have to search all the code in the procedure, if maybe it is used in a loop.
That is a big step down from the comfort we currently have of knowing the "var" declaration has a complete list.

Well it could be solved (but I still do not like it, for all the other reasons)
Code: Pascal  [Select][+][-]
  1. procedure Foo;
  2. var
  3.   i: integer iterator; // this var is only allowed as loop iterator in for loops
  4. begin
  5.   for i := 0 to 9 do

that would at least keep the declaration on top. yet the compiler would be able to do all the checks that you wanted.


3)
Quote
make code a little more reliable
between compiler updates
Please explain?

4)
Quote
This would stop those from trying to use the value of the loop when it exits
I doubt it. They would simple use the syntax with the normal pre-declared variable that we have today.

It is only useful for those who already know that the variable can not be used afterwards.
Those would therefore actively and understandingly choose this syntax as a way to get an error should they accidentally get it wrong.
But they could also choose -Sew if the compiler had the correct warning.
 
So it really looks like the missing warning would do the entire job.



kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Please make your language more freedom
« Reply #72 on: June 24, 2018, 09:56:19 am »
And that is my point, if this (declaring variables anywhere) is NOT good for other control blocks (like "if" or any other), then what makes "for" so special?
I think the speciality of the 'for' iterator is quite obvious. A 'for..to' loop always has exactly one iterator. The iterator variable of the loop is read/write outside the loop, but readonly within the loop. I'm sure there were some efforts involved in the compiler design to make it working that way. One could say its an abuse of a standard variable, as their properties are changed in the certain block. Of course in a if-block nothing like that happens to a variable.

But still, the iterator variable needs a space in memory. This has a certain size and location. The iterator could be defined as local or global variable. There may be reasons for both, especially in embedded programming. So a declaration is required and the var section is the correct place for that.
Still, a self-declared iterator variable could be allowed. Then the compiler checks if the iterator was declared before or not. If not, then it organizes the iterator as local Integer variable. If already declared than it's the same as now. This even would ensure backward compatibility. This would be an introduction of self decleration, a simple typo could change the type of the iteration variable if a explicit declared variable was intended. I see that this is not part of the pascal philosophy...
Also doing an (optional) explicit decleration could become a 'hidden' feature, not intuitive any more.

If I have many 1 liner loops, I reuse the var, if some of them are "while" loops, I still reuse the var.
Thats a good point. (Would still be possible with a "dual" approach).


Quote
What makes the uninitialized var after a loop so different to other uninitialized var?
For me its quite strange that the variable is initialized if the loop was interrupted by break/goto but not if it was properly finished. If I want to use the feature in case that the loop was interrupted than I first have to check if the loop even was interrupted, otherwise I couldn't rely on the iteration variables value. This means flags or something is needed. But instead such efforts I could just copy the iteration variable inside the loop, so that feature seems useless...
In Fortran (90?) the iteration variable after a "smooth" loop ending has the value one step higher then the upper loop bound. That sounds strange, but with this its possible to know by the iteration variable's value if the loop was interrupted or left smoothly, as the value of an interruption in the last cycle is the loop's upper bound.

Is there a certain reason that the value after the full loop is not defined?

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #73 on: June 24, 2018, 01:41:12 pm »
And that is my point, if this (declaring variables anywhere) is NOT good for other control blocks (like "if" or any other), then what makes "for" so special?
I think the speciality of the 'for' iterator is quite obvious. A 'for..to' loop always has exactly one iterator. The iterator variable of the loop is read/write outside the loop, but readonly within the loop.
Well, point to you, good answer.

This is probably out of the need of an implementation detail, which allows the compiler to optimize the loop behaviour, but nevertheless.

I am not sure, if I want this to be extended. Actually I am quite sure I do not, but that is personal opinion.
But in this case (and while I do NOT vote for it), I would say the way to extend this, would be to add a modifier in the var section
Code: Pascal  [Select][+][-]
  1. var
  2.   i: integer iterator;
and keep the for loop as it is.
That is the "for" loop can NOT declare a new variable, it has to use one from the "var" declaration (a modeswitch may be introduced to force it to only use "marked" ones)
Any variable marked as "iterator" (or whatever the keyword) will only be allowed to be used as "for" loop iterator and nowhere else.

This however would be mainly to highlight the fact, that the variable is special (read only).
Any effect it has on the uninitialized issues, would be a mere side effect. Otherwise we would need lots of other special flags, for other cases of uninitialized vars.

This would for example allow to prevent the following:
Code: Pascal  [Select][+][-]
  1. procedure Bar;
  2. var
  3.   i: Integer;
  4.  
  5.   procedure Foo;
  6.   begin
  7.     i:=9; // we can modify i here, which can cause all kind of undesired effects
  8.   end;
  9. begin
  10.   for i := 1 to 10 do begin
  11.     Foo;
  12.     writeln(i);
  13.   end;
  14. end;
  15.  

And by the way, this example only works, if the "iterator" variable can be read outside the loop (assuming Foo would read, instead of write). And that would include "after the loop" too (Foo could be called after the loop).

So this example shows, that a variable with a scope set to the loop itself, would actually break existing language features. (the feature being reading the var in Foo, not the abuse of writing to it)
Yes I know it is optional, but if there are cases where it can not be used at all (not even optional), then that means that even if you want the feature you are left with some code that even you must write in the old way, and even you still will not get the "protection" you seek.
So the new feature would be incomplete

Therefore: "var   i: integer iterator;" should make it read-only, but still allow access anywhere.

Quote
But still, the iterator variable needs a space in memory. This has a certain size and location. The iterator could be defined as local or global variable. There may be reasons for both, especially in embedded programming. So a declaration is required and the var section is the correct place for that.
At the moment "for" iterators must be local variables. (probably due to the same implementation detail)

Quote
Still, a self-declared iterator variable could be allowed.
IMHO, no.

But: Why?
What extra good would they bring?

Quote
This would be an introduction of self decleration, a simple typo could change the type of the iteration variable if a explicit declared variable was intended. I see that this is not part of the pascal philosophy...
You argue my case. Thanks.


Quote
Quote from: Martin_fr
What makes the uninitialized var after a loop so different to other uninitialized var?
For me its quite strange that the variable is initialized if the loop was interrupted by break/goto but not if it was properly finished. If I want to use the feature in case that the loop was interrupted than I first have to check if the loop even was interrupted, otherwise I couldn't rely on the iteration variables value. This means flags or something is needed. But instead such efforts I could just copy the iteration variable inside the loop, so that feature seems useless...
This is an argument why the "break" behaviour is not a good idea (though exceptions, and an "except" block would work).

But it does not answer my question. My understanding is this:
A loop iterator is uninitialized after the loop. We want protection from accidentally using an uninitialized variable (I intentionally made this statement generic, applying to any uninitialized var).

- Why do we want special/extra protection, if that uninitialized var was a "for" iterator before?
- IMHO, *ALL* uninitialized deserve the same lever of attention/protection.
- An application certainly will be same as buggy if it hits an uninitialized var never mind if this was a "for" iterator, or otherwise uninitialized.

So again: What makes the uninitialized var after a loop so different to other uninitialized var?

« Last Edit: June 24, 2018, 01:46:13 pm by Martin_fr »

mercurhyo

  • Full Member
  • ***
  • Posts: 242
Re: Please make your language more freedom
« Reply #74 on: June 24, 2018, 03:11:23 pm »
Ok let it be "as it is", no problem to me it works for 35 years.
about generic class<curlymathsyms> I will never use that (I can't see a knife under my neck forcing me to use improvements I do not want, as I mentioned) unless I find a way to patch the compiler, replacing "<>" with "[ ]" that is more pascalish to my taste
DEO MERCHVRIO - Linux, Win10pro - Ryzen9XT 24threads + Geforce Rtx 3080SUPRIM
god of financial gain, commerce, eloquence (and thus poetry), messages, communication (including divination), travelers, boundaries, luck, trickery and thieves; he also serves as the guide of souls to the underworld

 

TinyPortal © 2005-2018