Recent

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

BeniBela

  • Hero Member
  • *****
  • Posts: 905
    • homepage
Re: Please make your language more freedom
« Reply #75 on: June 24, 2018, 04:12:55 pm »

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

It is the only case where an assignment makes the variable uninitialized

If you write i := something anywhere, the variable becomes  initialized. But when you write for i := 1 to 3, it is later uninitialized. It is like a weirdly overloaded := operator




Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #76 on: June 24, 2018, 05:04:07 pm »

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

It is the only case where an assignment makes the variable uninitialized

If you write i := something anywhere, the variable becomes  initialized. But when you write for i := 1 to 3, it is later uninitialized. It is like a weirdly overloaded := operator
Good point. (actually 2 good points)

*** Your first point (the one I guess you wanted to make)

The values for "i" are only valid inside the loop.

The same happens here:
Code: Pascal  [Select][+][-]
  1. function InitValue(out x: integer): boolean;
  2. begin
  3.   Result := somecondition;
  4.   if not result then exit; // x will not be initialized
  5.   x:= 1;
  6. end;
  7. precdure Foo;
  8. begin
  9.   if InitValue(i) then begin
  10.     // here i is initalized
  11.     writeln(i);
  12.   end;
  13. // i must be treated as undefined, because the InitBar may not have initialized it
  14.  

Ok, It is not an assignment, but an out parameter. But it servers the same purpose.

I admit it is not 100% identical...(so your point is still partly standing), but it leads to the very same situation, and there is no "for" involved.

*** Your 2nd point
Quote
for i := 1 to 3, it is later uninitialized. It is like a weirdly overloaded := operator
You are absolutely right. There is something very weird about the := here.

What is actually assigned to "i", and when?

- This := can not be, because the right hand site does not provide a single value of the type. (even "1 to 1" is a range)
- So this := promises us that "i" will be assigned a range of its base type? That can not be.

The fix must then be to remove this := from the for loop.

Then there no longer is an assignment, and there is no contradiction that "i" is uninitialized in the end.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: Please make your language more freedom
« Reply #77 on: June 25, 2018, 09:34:58 am »
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
Using "[…]" is just as much hell for the parser as "<…>" already is as the former conflicts with the array syntax while the latter conflicts with comparisons. Also considering that the "[…]" syntax in const/var sections means sets (which are unordered) a more correct choice would be "(…)" which is for ordered elements in those sections and the type parameters are ordered.

mercurhyo

  • Full Member
  • ***
  • Posts: 242
Re: Please make your language more freedom
« Reply #78 on: June 25, 2018, 11:14:35 am »
@PascalDragon
at the moment, I do not need C templates so I just put my opinion around curly syntax. IF and ONLY IF one day, I would need templates in pascal, I will modify the compiler TO MY pascalish taste. I had no deep reflexion so far, I am just pointing the unlogic C notation, even if it comes from delphi... I don't care
« Last Edit: June 25, 2018, 11:19:33 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

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Please make your language more freedom
« Reply #79 on: June 25, 2018, 12:40:37 pm »
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.
This is probably out of the need of an implementation detail, which allows the compiler to optimize the loop behaviour, but nevertheless.
[...]
That is the "for" loop can NOT declare a new variable
You take a different conclusion of my argument than me. What I mean is: Because the iterator variable is that special, directly tied to the loop and in almost all cases of local integer type. Because of this it feels a waste of time to do a declaration (of something obvious). So the aim is to make things less complicated (by omitting the decleration) and not to make them more complicated by additionally forced flags like "iterator".

And thats the answer to the "why": To reduce efforts. Avoid that the programmers has to consider things that the compiler can do itself.

Quote
This would for example allow to prevent the following:
[...] we can modify i here, which can cause all kind of undesired effects
Thats a crazy hack. But I apreciate the example of how easy it is to "actually break existing language features".

Quote
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.
I don't seek any protection, but simplycity :) The arguments about the uninitialised variable in my point of view is not about that protection after the loop is needed, but that the other way round there is no reason why the loop variable after the loop still should be accessible at all.

Quote
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.
To be honest, if I had the power I wouldn't want to have to decide it. There are pros and cons. Both imo strong ones.


Quote
- 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?
In contrast to the documentation the practice shows the bahaviour that the variable is initialized to the last loop's value (At least in cases). Also this is a common feature of many programming languages.
BUT: I wouldn't add protection because of that. Rather I'd make it a documented feature.



What is actually assigned to "i", and when?
- This := can not be, because the right hand site does not provide a single value of the type. (even "1 to 1" is a range)
- So this := promises us that "i" will be assigned a range of its base type? That can not be.
I read it like that (for i:= 1 to 3): "loopwise assign values for i starting with 1 ending with 3", i.e.:
i:= 1
...continue
i:=2
...continoue
i:=3
...break
So the variable should stay at the upper bound after smoothly leaving the loop.

At the moment "for" iterators must be local variables. (probably due to the same implementation detail)
I tested and its possible to use a Integer declared in an other unit (making it global). I'm not sure though if the loop is actually using that address or kept locally, or is even optimized to registers.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #80 on: June 25, 2018, 02:01:48 pm »
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.
This is probably out of the need of an implementation detail, which allows the compiler to optimize the loop behaviour, but nevertheless.
[...]
That is the "for" loop can NOT declare a new variable
You take a different conclusion of my argument than me. What I mean is: Because the iterator variable is that special, directly tied to the loop and in almost all cases of local integer type. Because of this it feels a waste of time to do a declaration (of something obvious). So the aim is to make things less complicated (by omitting the decleration) and not to make them more complicated by additionally forced flags like "iterator".

And thats the answer to the "why": To reduce efforts. Avoid that the programmers has to consider things that the compiler can do itself.

So now it is NOT about the uninitialized behaviour of the iterator after the loop. But it is about "saving to type a few extra chars". Is that correct?

Actually, I have plenty of loops that iterate over other enum types. (Search the IDE for "procedure dbgs" / typical pattern: for i := low(enumtype) to high(...)...)

But even if it was mostly integer. The declaration of any variable on top, tells me more than the type it has. It tells me the name is used as an identifier.
As I wrote before in this thread, if the loop iterator would not be declared in the var block, and I wanted to add a variable (for none loop purpose), then I would have to search the entire procedure body for any "for" loops, so I know the name is not used. That is a massive amount of extra work.
So in order to know about all the identifier names that are already used in the procedure, the iterator too must be listed in the var block. (never mind in which way, but it must be there)

Further more
Code: Pascal  [Select][+][-]
  1.  for i := 0 to foo.count -1
foo.count may be cardinal. Mixed signed expression may give a 64 bit result. But I most likely do not want "i" to  be int64. So I do need to specify it.
Or I may want I to be a smaller type, because it will never exceed it, and a lot of operations in the loop depend on it.

Of course, I understand, if I need a type different from the declared type, then I can still set it. But that is not all of it. "foo.count" may change from integer to cardinal, after I wrote the loop.
If there even is as much as the possibility that I have somewhere a loop that uses the derived type for the iterator, rather than a declared type, then I will have to search my entire code base (and that really is a lot of work, especially if the change is in a package on which many projects depend).
So for that reason I need the compiler to enforce that the type of the iterator is always declared.

And finally (and on that your opinion may differ), I prefer it that if foo.count changes to an incompatible type, then the compiler will not compile the loop.
So I can check it, if changing the declared type will work as I expect it, or if it will have side effects. (assuming the loop body compiles with the new iterator type, otherwise the derived iterator will give an error too)

Besides:
Quote
To reduce efforts.
If you do not want to give it much attention, how much effort is it to press Ctrl-Shift-C (you can even assign it to something easier)?
Codetool will do it for you, if you ask it.

<half sarcasm>
If you want to save keystrokes (I understand the above may also be, saving to think about what type will be needed). You can add a code template, so that typing
"{ " will expand to "begin ". Saves 4 keystrokes (and 2 in case of end) ;)
</half sarcasm>


Quote

Quote
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.
I don't seek any protection, but simplycity :) The arguments about the uninitialised variable in my point of view is not about that protection after the loop is needed, but that the other way round there is no reason why the loop variable after the loop still should be accessible at all.
Equally I could say there is no reason why it should not be available (Especially after you wrote, you don't seek protection from accidentally accessing it).

It can even be convenient to have the variable for other purposes (as long as you initialize it). IMHO having it around increases simplicity. Otherwise I may need additional other vars for use after the loop. More vars needed => less simplicity.

Quote
To be honest, if I had the power I wouldn't want to have to decide it. There are pros and cons. Both imo strong ones.

Well yes, people have given actual arguments for both sides. IMHO the pro were not very convincing, but that is based on personal bias.

There are quite a few people (if not the majority), who have not gone beyond opinion. I have to assume (and I would understand that), that they come from a language in which it works the way the want it.
It can be hard to go from one language to another, you are used to structure your problems and code according to the features of the language you used. (been there done that).
"being used to it" is no argument.
Neither is "c or js have it" an argument. Then I could say in some languages I do not need to declare vars at all.... (they all get derived from context, and casted if needed)

One of the principals of pascal is that you give a type to each variable (that includes iterators).
Well yes it is broken already, there is an untyped parameter. But at least you still have to explicitly typecast it, to use it. (Not something you want to do with the iterator).

Quote
Quote
- 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?
In contrast to the documentation the practice shows the bahaviour that the variable is initialized to the last loop's value (At least in cases). Also this is a common feature of many programming languages.

Code: Pascal  [Select][+][-]
  1. program Project1;{$mode objfpc}{$H+}
  2. var i: integer;
  3. begin
  4.   for i := 2 to 9 do writeln();
  5.   writeln(i);
  6.   readln;
  7. end.

Compile with -O4
I get "0".

Quote
BUT: I wouldn't add protection because of that. Rather I'd make it a documented feature.
Ok, so that would be a different new feature.

If it where to be implemented, no objections from me.
But I would severely hope the optimizer in fpc would be enhanced for enough to detect, if the iterator is needed after the loop. So in cases were it is not needed, the loop can still be optimized. Would be a shame to loose clock cycles in all loops.

Quote
What is actually assigned to "i", and when?
I read it like that (for i:= 1 to 3): "loopwise assign values for i starting with 1 ending with 3", i.e.:
Well we all got used to read it like this.
But none the less, the 3 statement you made out of it (which each have an RHS evaluating to a single value of the correct type) are not part of the written source code.
And the actual present ":=" does not have a RHS that returns a value of the type.

I agree that the := in the "for" statement misleads to the assumption that there will be the assignments you stated. But that is: it "misleads". So if that is the problem, then lets fix it.

And to be precise the proposed (with or without the ":integer" part)
Code: Pascal  [Select][+][-]
  1. for var I: integer := 1 to 3 do begin end;
would mislead as well.

The "var i" is not within the "begin/end" scope. So why would I assume it to be limited to that scope. I would of course assume, that it will be scoped to the end of the procedure (or maybe enclosing begin/end, if there was another).
Same as I would do in this case:
Code: Pascal  [Select][+][-]
  1.   if a= b then begin
  2.      foo();
  3.      var c: integer;  // statement declaring c, ends at the ";"
  4.      if bar() then begin
  5.         c:= 1;
  6.      end;
  7.      c := 2;
  8.   end;  // scope for c ends here
  9.  

It may be different in c/js, but why would I even think about rules of a language that is not the one I currently write code in?

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Please make your language more freedom
« Reply #81 on: June 25, 2018, 07:55:53 pm »
But it is about "saving to type a few extra chars". Is that correct?
No, its not about typing a few extra chars. Its about taking an additional step/action. When one is very common to a programming language than this doesn't matter as its automated in mind (or by IDE-help). The same holds for begin..end. I like "end" but I don't like "begin". The few more characters don't matter at all. But I don't 'feel' the block of a if-condition or for-loop. For me "for i:=1 to 5 do begin" is the head of the loop, "end;" is the tail of the loop. In this way of thinking the "begin" keyword is absolutely useless. I would say its only there to allow single statement loops. Again, for someone with experience in a language this gets automized and doesn't matter at all. By now I feel nearly indifferent to it. When starting with Freepascal it was quite annoying though. The importance of such features is not easy to grap, to quantify or whatever, as its not hard objective facts. But all programmers are humans having emotions and liking or not liking a language is part of the game. (In general - obviously - I really like Freepascal).

Quote
"foo.count" may change from integer to cardinal, after I wrote the loop.
If there even is as much as the possibility that I have somewhere a loop that uses the derived type for the iterator, rather than a declared type, then I will have to search my entire code base
[...]
And finally, I prefer it that if foo.count changes to an incompatible type, then the compiler will not compile the loop.
I don't exactly understand. If the compiler always choses an Integer type for undeclared loop variables and foo.count changes to cardinal, then its the same situation as I would have declared the integer manually (because I also choose Integer as standard).


Quote
Actually, I have plenty of loops that iterate over other enum types. (Search the IDE for "procedure dbgs" / typical pattern: for i := low(enumtype) to high(...)...)
Yes, my view point may be limited, I very rarely use enumerators.

Quote
But even if it was mostly integer. The declaration of any variable on top, tells me more than the type it has. It tells me the name is used as an identifier.
As I wrote before in this thread, if the loop iterator would not be declared in the var block, and I wanted to add a variable (for none loop purpose), then I would have to search the entire procedure body for any "for" loops, so I know the name is not used. That is a massive amount of extra work.
Is this a real issue? My loops mostly have standard names and I wouldn't use a loop variable as a temporary integer just because its lying around.

Quote
Quote
BUT: I wouldn't add protection because of that. Rather I'd make it a documented feature.
Ok, so that would be a different new feature.

If it where to be implemented, no objections from me.
But I would severely hope the optimizer in fpc would be enhanced for enough to detect
Agreed. It's like always, considering all circumstances makes a small change quite troublesome if it is done right.


Quote
It may be different in c/js, but why would I even think about rules of a language that is not the one I currently write code in?
There's always space for improvement. For many features its clear that they use a different philosophy, but not for all.

--
From my side we don't need to dig any deeper into that topic. I'm already convinced that there are some pitfalls. Perhaps thats such kind of feature where only actual usage could clarify the benefits and costs. Of course thats not easily possible.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Please make your language more freedom
« Reply #82 on: June 25, 2018, 08:11:11 pm »
Quote
From my side we don't need to dig any deeper into that topic. I'm already convinced that there are some pitfalls. Perhaps thats such kind of feature where only actual usage could clarify the benefits and costs. Of course thats not easily possible.

Ack.

As for the first paragraph of your message.
Yes moving between languages has its annoyances. But to me that is NOT a matter of changing the one or the other (yes it could be the other) language. They differ, so be it.

<sarcasm>
Next topic: Should shell script support object orientation?
</sarcasm>


Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Please make your language more freedom
« Reply #83 on: June 25, 2018, 08:35:14 pm »

<sarcasm>
Next topic: Should shell script support object orientation?
</sarcasm>
<cynism>
Windows PowerShell anyone?
</cynism>
Note one could argue that instantfpc is an OOP extension to shell scripts... :D
Code: Pascal  [Select][+][-]
  1. #!/usr/bin/env instantfpc
  2. // save as ps.pas
  3. // chmod +x ps.pas
  4. // ./ps.pas
  5. {$mode objfpc}
  6. uses classes;
  7. begin
  8.   with Tstringlist.create do
  9.   try
  10.     Add('Hello, Object Scripting (well actually compiling and caching)');
  11.     writeln(Text);
  12.   finally
  13.     free;
  14.   end;
  15. end.
« Last Edit: June 25, 2018, 08:46:34 pm by Thaddy »
Specialize a type, not a var.

Thaddy

  • Hero Member
  • *****
  • Posts: 14201
  • Probably until I exterminate Putin.
Re: Please make your language more freedom
« Reply #84 on: June 25, 2018, 08:56:21 pm »
No, its not about typing a few extra chars. Its about taking an additional step/action. When one is very common to a programming language than this doesn't matter as its automated in mind (or by IDE-help). The same holds for begin..end. I like "end" but I don't like "begin".
You seem to forget that the curly brackets mob have the same issue and for the same reason: "{" is short for "begin", "}" is short for "end" nothing less, nothing more.
If anything, Pascal syntax is shorter in the single statement case, because you can drop begin end, comma's and all kind of ++ either side of the index variable (that you have to type twice!. :D :D :o 8-) O:-)
Code: Pascal  [Select][+][-]
  1. var i:integer;
  2. begin
  3.    for i := 0 to 9 do writeln(i);
  4. end.
« Last Edit: June 25, 2018, 09:35:08 pm by Thaddy »
Specialize a type, not a var.

kupferstecher

  • Hero Member
  • *****
  • Posts: 583
Re: Please make your language more freedom
« Reply #85 on: June 25, 2018, 10:54:41 pm »
In case there was a misunderstanding: I don't come from any c-like language.

"{" is short for "begin", "}" is short for "end" nothing less, nothing more.
Yes, begin..end is nearly as bad as {}. The modula-2 syntax is much better.
 :)

BeniBela

  • Hero Member
  • *****
  • Posts: 905
    • homepage
Re: Please make your language more freedom
« Reply #86 on: June 26, 2018, 01:22:43 am »

So now it is NOT about the uninitialized behaviour of the iterator after the loop. But it is about "saving to type a few extra chars". Is that correct?


It is both.

when I was writing a lot of code, saving typing was very important to me

But now my project is mostly finished, and I spent more time debugging issues, and the worst kind of bugs have turned out to be uninitialized variables that had compiled without warning and passed all tests, till something somewhere else changed.


As I wrote before in this thread, if the loop iterator would not be declared in the var block, and I wanted to add a variable (for none loop purpose), then I would have to search the entire procedure body for any "for" loops, so I know the name is not used. That is a massive amount of extra work.
So in order to know about all the identifier names that are already used in the procedure, the iterator too must be listed in the var block. (never mind in which way, but it must be there)

But you can have multiple variables with the same name, like in nested functions or a with block

Further more
Code: Pascal  [Select][+][-]
  1.  for i := 0 to foo.count -1
foo.count may be cardinal. Mixed signed expression may give a 64 bit result. But I most likely do not want "i" to  be int64. So I do need to specify it.
Or I may want I to be a smaller type, because it will never exceed it, and a lot of operations in the loop depend on it.

Of course, I understand, if I need a type different from the declared type, then I can still set it. But that is not all of it. "foo.count" may change from integer to cardinal, after I wrote the loop.
If there even is as much as the possibility that I have somewhere a loop that uses the derived type for the iterator, rather than a declared type, then I will have to search my entire code base (and that really is a lot of work, especially if the change is in a package on which many projects depend).[/u]

And finally (and on that your opinion may differ), I prefer it that if foo.count changes to an incompatible type, then the compiler will not compile the loop.
So I can check it, if changing the declared type will work as I expect it, or if it will have side effects. (assuming the loop body compiles with the new iterator type, otherwise the derived iterator will give an error too)



Type safe integers? This is already messed up. The compiler does not do shit about type safety. At most we can expect a runtime error.

This compiles and never runs the loop:

Code: [Select]
var i: integer;
    n: cardinal;
begin
  n := MaxInt + 2;
  writeln(n);
  for i := 0 to n - 1 do begin
    writeln(i);
  end;
end.

This compiles and runs the loop many many times:

Code: [Select]
var i: cardinal;
    n: cardinal;
begin
  n := 0;
  writeln(n);
  for i := 0 to n - 1 do begin
    writeln(i);
  end;
end.

And this prints 10000. Apparently all smaller types are converted to sizeint/sizeuint when used

Code: [Select]
var b: byte;
begin
  b := 100;
  writeln(b * b);
end.

It would be much safer when the compiler chooses a fitting type, because then you cannot forget to change the type of a for loop when the count property changes its type



The "var i" is not within the "begin/end" scope. So why would I assume it to be limited to that scope. I would of course assume, that it will be scoped to the end of the procedure (or maybe enclosing begin/end, if there was another).
Same as I would do in this case:
Code: Pascal  [Select][+][-]
  1.   if a= b then begin
  2.      foo();
  3.      var c: integer;  // statement declaring c, ends at the ";"
  4.      if bar() then begin
  5.         c:= 1;
  6.      end;
  7.      c := 2;
  8.   end;  // scope for c ends here
  9.  

It may be different in c/js, but why would I even think about rules of a language that is not the one I currently write code in?


You are thinking too much about C

In Pascal the var always defines the variable for the next begin..end, and not for some other begin..ends


Code: [Select]
function a;
  function b;
  var i: integer;
  begin
     //i in scope
  end;
begin
   //i not in scope
end;



var _within_ begin..end could also be useful though

mercurhyo

  • Full Member
  • ***
  • Posts: 242
Re: Please make your language more freedom
« Reply #87 on: June 26, 2018, 02:09:40 am »
plus the fact there are problems on containers limits

assuming MyContnr owns objects and frees them
Clear entire container,
for i:=0 to Pred(MyContnr.Count) do delete MyContnr.items[ i ]; // Count is decreasing, it is bad
in such case prefer
for i:=Pred(MyContnr.Count) DOWNTO 0 ... // limit is const
or while (count> 1) delete items[Pred(count)];

meaning loops with non const limits are dangerous to newbies and more lol

now clear parts only,
deleting items 13..71 then 189..191 on a 200 items TFPObjectList isn't an evidence LOL
assuming you dont want to call "pack" each iteration
« Last Edit: June 26, 2018, 11:15:16 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

VTwin

  • Hero Member
  • *****
  • Posts: 1215
  • Former Turbo Pascal 3 user
« Last Edit: June 26, 2018, 04:02:12 am by VTwin »
“Talk is cheap. Show me the code.” -Linus Torvalds

Free Pascal Compiler 3.2.2
macOS 12.1: Lazarus 2.2.6 (64 bit Cocoa M1)
Ubuntu 18.04.3: Lazarus 2.2.6 (64 bit on VBox)
Windows 7 Pro SP1: Lazarus 2.2.6 (64 bit on VBox)

tr_escape

  • Sr. Member
  • ****
  • Posts: 432
  • sector name toys | respect to spectre
    • Github:
Re: Please make your language more freedom
« Reply #89 on: June 28, 2018, 09:58:09 pm »
This is freedom:

 :D

No, I think this coding style is freedoom :)


Every year I am focusing to a new topic about Modern pascal , Future of pascal , New IDE idea,Modern UI in Lazarus so on...

So actually I have some bookmarks for about fpc/lazarus's future thats: (Not tidy order)

1- This thread

2- http://forum.lazarus.freepascal.org/index.php/topic,41633.0.html

3- http://forum.lazarus.freepascal.org/index.php/topic,40774.0.html

4- http://forum.lazarus.freepascal.org/index.php/topic,31971.0.html

5- http://forum.lazarus.freepascal.org/index.php/topic,13754.0.html

6- http://forum.lazarus.freepascal.org/index.php/topic,36502.0.html

Ideas never ends (thats the key and it is good thing) but fpc/lazarus team haven't got a lot of resources.

The main resource is team and time , if team members spending a lot of time for answering whole questions when they will continue to developing for project?

 

TinyPortal © 2005-2018