Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2015-10

Fwd: While - Otherwise Statement

21 messages · 12 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Max Nazhalov
Show quoted text 9 lines
I can't think of a use case either. And just because another language provides such a solution, does not imply that FPC should. As to achieving the functionality in FPC: if cond then while cond do foo else bar;

That's what I've thought about from the beginning of this discussion..

---
WBR, Max.

Reply by email

Max Nazhalov
Show quoted text 11 lines
> I can't think of a use case either. And just because another language > provides such a solution, does not imply that FPC should. As to achieving > the functionality in FPC: > > if cond then > while cond do > foo > else > bar; That's what I've thought about from the beginning of this discussion..

The only drawback is that "cond" is calculated twice instead of once before the actual loop body -- not all will be happy.. ;-)

WBR, Max.

Reply by email

Martin Frb
to Max Nazhalov
Max Nazhalov wrote
>> I can't think of a use case either. And just because another language >> provides such a solution, does not imply that FPC should.

+1

(despite my earlier contribution)

Discussion of the feature below, is regardless of it not being desirable (in any form)

Show quoted text 9 lines
>> As to achieving >> the functionality in FPC: >> >> if cond then >> while cond do >> foo >> else >> bar; > That's what I've thought about from the beginning of this discussion..

Actually the above does not represent what the actual feature request is about

The "else" is to be executed, after the while (even if the while looped ZERO times).
But it is to be skipped if the while exited via break (and only then).

For that reason "else" or "otherwise" are badly chosen keywords. Because they imply a different function.

<sarcasm on>

Further what is so special about the case "finishing a while loop without break (including 0 iterations)"?
If that case deserves special attention then surely the following also need (and no one should want all that)

while cond
initialize // run before the 1st loop, if there is going to be at least one loop
do // each loop
finalize // run after last loop, if there was at least one finalizeThen // run after last loop, if there was at least one // only if no break
finalizeCatch // run after last loop, if there was at least one // only if a break happened
then // finish, without break; or zero loops
catch // only on break
else // if there was no loop at all (condition was wrong, before first loop already)

There are all equally (none-) important. Have one have all. <sarcasm off>

Better have none.

The only drawback is that "cond" is calculated twice instead of once before the actual loop body -- not all will be happy.. ;-)

Thats an issue for the optimizer. no need to change the language.

Reply by email

Unknown author
to Martin Frb
Martin Frb wrote 8 lines
Actually the above does not represent what the actual feature request is about The "else" is to be executed, after the while (even if the while looped ZERO times). But it is to be skipped if the while exited via break (and only then). For that reason "else" or "otherwise" are badly chosen keywords. Because they imply a different function.

exactly my and others' points... "and" would be better but then one might just as easily use a goto to jump around that part if break was used to get out of the loop...

anyway, it seems that no matter what the discussion, it won't make it into the compiler... that according to another post from a compiler dev ;)

NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email

Sven Barth
to Unknown author: exactly my and others' points... "and" would be better but then one might just as easily…
anyway, it seems that no matter what the discussion, it won't make it

into the compiler... that according to another post from a compiler dev ;)

I said that I'm not sure. Right now I'm considering that mostly as way for the author to learn about the ways to extend the compiler and what would be needed for a feature patch to be accepted.

Whether this specific feature would be added or not is a different topic.

Regards,
Sven

Reply by email

Unknown author
to Sven Barth
Sven Barth wrote 6 lines
Am 12.10.2015 22:48 schrieb < >: > anyway, it seems that no matter what the discussion, it won't make it into the compiler... that according to another post from a compiler dev ;) I said that I'm not sure.

it wasn't you that made that statement but if you are willing to add it, i guess maybe it will make it ;)

Right now I'm considering that mostly as way for the author to learn about the ways to extend the compiler and what would be needed for a feature patch to be accepted.

that's great! it can be a tough row to hoe learning what the proper workflow is when contributing to any project...

Whether this specific feature would be added or not is a different topic.

+1

NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email

Michael Van Canneyt
to Unknown author: exactly my and others' points... "and" would be better but then one might just as easily…
Show quoted text 19 lines
On 10/12/2015 03:43 PM, Martin Frb wrote: > Actually the above does not represent what the actual feature request is > about > > The "else" is to be executed, after the while (even if the while looped > ZERO > times). > But it is to be skipped if the while exited via break (and only then). > > For that reason "else" or "otherwise" are badly chosen keywords. Because > they > imply a different function. exactly my and others' points... "and" would be better but then one might just as easily use a goto to jump around that part if break was used to get out of the loop... anyway, it seems that no matter what the discussion, it won't make it into the compiler... that according to another post from a compiler dev ;)

Maybe my remark was not clear.

I'm not against this *functionality*.

I merely pointed out that *the syntax using 'else'* is not going to make it because it breaks backwards compatibility.

If another keyword is used: no problem.

I don't understand why anyone would want this marginal functionality and thus (again) needlessly complicates the language, but hey, it's a (mostly) free world....

Alas, the monstrosity that Object Pascal syntax is becoming is less and less appealing by the day, it's simply frightening...

Michael.

Reply by email

Unknown author
to Michael Van Canneyt
Michael Van Canneyt wrote 27 lines
On Mon, 12 Oct 2015, wrote: > On 10/12/2015 03:43 PM, Martin Frb wrote: >> Actually the above does not represent what the actual feature request is about >> >> The "else" is to be executed, after the while (even if the while looped ZERO >> times). >> But it is to be skipped if the while exited via break (and only then). >> >> For that reason "else" or "otherwise" are badly chosen keywords. Because they >> imply a different function. > > exactly my and others' points... "and" would be better but then one might just > as easily use a goto to jump around that part if break was used to get out of > the loop... > > anyway, it seems that no matter what the discussion, it won't make it into the > compiler... that according to another post from a compiler dev ;) Maybe my remark was not clear. I'm not against this *functionality*. I merely pointed out that *the syntax using 'else'* is not going to make it because it breaks backwards compatibility.

ahhhh... my bad... sorry 'bout that... i've been thinking about this, too... 'else' and 'otherwise' mean the same thing... what they seem to be looking for is 'aswell'...

foo := 0;
while foo < 100 do
   begin
     inc(foo);
   end;
aswell
   begin
     dec(foo);
   end;

either 'aswell' or 'aswellas'... while foo is less than 100 increment foo as well as decrement foo when it is no longer less than 100...

i don't see a need for it because in this case if one wants foo to only get to 99, then they should use 99 as their count...

foo := 0;
while foo < 99 do
   begin
     inc(foo);
   end;

at the end of the loop, foo will equal 99... but it is also a very simple example...

If another keyword is used: no problem.

ok...

Show quoted text 6 lines
I don't understand why anyone would want this marginal functionality and thus (again) needlessly complicates the language, but hey, it's a (mostly) free world.... Alas, the monstrosity that Object Pascal syntax is becoming is less and less appealing by the day, it's simply frightening...

it seems that way... but it doesn't mean that we have to use it... we can stay with the traditional ways and means within whatever it becomes as long as they don't change with these undesirable extensions...

NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email

Mark Morgan Lloyd
to Unknown author
Show quoted text 54 lines
On 10/13/2015 04:32 AM, Michael Van Canneyt wrote: > > > On Mon, 12 Oct 2015, wrote: > >> On 10/12/2015 03:43 PM, Martin Frb wrote: >>> Actually the above does not represent what the actual feature >>> request is about >>> >>> The "else" is to be executed, after the while (even if the while >>> looped ZERO >>> times). >>> But it is to be skipped if the while exited via break (and only then). >>> >>> For that reason "else" or "otherwise" are badly chosen keywords. >>> Because they >>> imply a different function. >> >> exactly my and others' points... "and" would be better but then one >> might just >> as easily use a goto to jump around that part if break was used to >> get out of >> the loop... >> >> anyway, it seems that no matter what the discussion, it won't make it >> into the >> compiler... that according to another post from a compiler dev ;) > > Maybe my remark was not clear. > > I'm not against this *functionality*. > > I merely pointed out that *the syntax using 'else'* is not going to > make it > because it breaks backwards compatibility. ahhhh... my bad... sorry 'bout that... i've been thinking about this, too... 'else' and 'otherwise' mean the same thing... what they seem to be looking for is 'aswell'... foo := 0; while foo < 100 do begin inc(foo); end; aswell begin dec(foo); end; either 'aswell' or 'aswellas'... while foo is less than 100 increment foo as well as decrement foo when it is no longer less than 100...

If somebody really has to do this wouldn't "also" be a better choice to avoid (getting close to overloading "as"? :-/

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Unknown author
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 22 lines
wrote: > ahhhh... my bad... sorry 'bout that... i've been thinking about this, too... > 'else' and 'otherwise' mean the same thing... what they seem to be looking for > is 'aswell'... > > > foo := 0; > while foo < 100 do > begin > inc(foo); > end; > aswell > begin > dec(foo); > end; > > > either 'aswell' or 'aswellas'... while foo is less than 100 increment foo as > well as decrement foo when it is no longer less than 100... If somebody really has to do this wouldn't "also" be a better choice to avoid (getting close to overloading "as"? :-/

it might... i don't know anything about "as" because i've never used it... what does it do?

NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email

Ralf Quint
to Michael Van Canneyt: Maybe my remark was not clear. I'm not against this *functionality*. I merely pointed out…
Michael Van Canneyt wrote 8 lines
I don't understand why anyone would want this marginal functionality and thus (again) needlessly complicates the language, but hey, it's a (mostly) free world.... Alas, the monstrosity that Object Pascal syntax is becoming is less and less appealing by the day, it's simply frightening...

+1

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Reply by email

Sven Barth
to Unknown author: it might... i don't know anything about "as" because i've never used it... what does it…
> > If somebody really has to do this wouldn't "also" be a better choice to

avoid

> (getting close to overloading "as"? :-/ it might... i don't know anything about "as" because i've never used

it... what does it do?

It's an operator for casting classes and interfaces in a safe way (which means that an exception is raised if the cast fails).

See here:
http://www.freepascal.org/docs-html/ref/refsu47.html#x141-15100012.8.7

Regards,
Sven

Reply by email

Martin Frb
to Mark Morgan Lloyd: If somebody really has to do this wouldn't "also" be a better choice to avoid (getting…
Show quoted text 19 lines
> ahhhh... my bad... sorry 'bout that... i've been thinking about this, > too... 'else' and 'otherwise' mean the same thing... what they seem > to be looking for is 'aswell'... > > > foo := 0; > while foo < 100 do > begin > inc(foo); > end; > aswell > begin > dec(foo); > end; > > > either 'aswell' or 'aswellas'... while foo is less than 100 increment > foo as well as decrement foo when it is no longer less than 100...

I am not native English, but aswell to me implies "do both" and gives no order.
So I would expect this (the aswell block) to be executed for each iteration too. like the perl continue block
http://perldoc.perl.org/functions/continue.html

btw, while I am not for it, the continue block appears much more useful than the "on-none-break" block. Though the continue block is not really ever needed, usually you can write the loop with the counter decrement at the top.

But the existence of such a continue block shows the fundamental issue on which a decision is needed. should (if a volunteer for a patch exists) every little "save one statement in your code helper" be added? Because there are thousands of them, and if you add them all the readability of code will go down, because you need to first learn them all.

Reply by email

Michael Van Canneyt
to Martin Frb
Martin Frb wrote 36 lines
wrote: >> ahhhh... my bad... sorry 'bout that... i've been thinking about this, >> too... 'else' and 'otherwise' mean the same thing... what they seem to be >> looking for is 'aswell'... >> >> >> foo := 0; >> while foo < 100 do >> begin >> inc(foo); >> end; >> aswell >> begin >> dec(foo); >> end; >> >> >> either 'aswell' or 'aswellas'... while foo is less than 100 increment foo >> as well as decrement foo when it is no longer less than 100... > I am not native English, but aswell to me implies "do both" and gives no order. So I would expect this (the aswell block) to be executed for each iteration too. like the perl continue block http://perldoc.perl.org/functions/continue.html btw, while I am not for it, the continue block appears much more useful than the "on-none-break" block. Though the continue block is not really ever needed, usually you can write the loop with the counter decrement at the top. But the existence of such a continue block shows the fundamental issue on which a decision is needed. should (if a volunteer for a patch exists) every little "save one statement in your code helper" be added? Because there are thousands of them, and if you add them all the readability of code will go down, because you need to first learn them all.

I think the answer to your question is a clear and loud "NO".

The argument that we can refrain from using these new features does not hold, because other people will be using it, and we will have to know all of it to be able to understand their code.
None of these features will automagically make Object Pascal a popular language.

However, I seem to be one of the very few thinking this given the enthousiasm with which people are discussing this.

Soon I will be forced to emigrate to Javascript country. Despite all its drawbacks, it remains at least a simple language. a dozen keywords and you're done. No wonder Node.js is so popular. Compare that with the jungle we're making of it... :(

Michael.

Reply by email

Mattias Gaertner
to Michael Van Canneyt: I think the answer to your question is a clear and loud "NO". The argument that we can…
[...] The argument that we can refrain from using these new features does not hold, because other people will be using it, and we will have to know all of it to be able to understand their code.

And it costs precious time of documentation and tool writers, who are already lacking behind. And every new feature makes the compiler a bit slower, costing time of all users.
Each new feature must present a solid case, why it is needed aka outweighs the downside.

None of these features will automagically make Object Pascal a popular language. However, I seem to be one of the very few thinking this given the enthousiasm with which people are discussing this.

Are you kidding?
Some people are already forking FPC because of such things.

Soon I will be forced to emigrate to Javascript country. Despite all its drawbacks, it remains at least a simple language. a dozen keywords and you're done. No wonder Node.js is so popular. Compare that with the jungle we're making of it... :(

Well, then you should vote against this new functionality.

Mattias

Reply by email

Martin Schreiber
to Michael Van Canneyt: I think the answer to your question is a clear and loud "NO". The argument that we can…
Michael Van Canneyt wrote 18 lines
> But the existence of such a continue block shows the fundamental issue on > which a decision is needed. should (if a volunteer for a patch exists) > every little "save one statement in your code helper" be added? Because > there are thousands of them, and if you add them all the readability of > code will go down, because you need to first learn them all. I think the answer to your question is a clear and loud "NO". The argument that we can refrain from using these new features does not hold, because other people will be using it, and we will have to know all of it to be able to understand their code. None of these features will automagically make Object Pascal a popular language. However, I seem to be one of the very few thinking this given the enthousiasm with which people are discussing this.

We are at least two people. :-)

Soon I will be forced to emigrate to Javascript country.

Or to MSElang? ;-)

Martin

Reply by email

Mark Morgan Lloyd
to Michael Van Canneyt: I think the answer to your question is a clear and loud "NO". The argument that we can…
Michael Van Canneyt wrote 18 lines
> But the existence of such a continue block shows the fundamental issue > on which a decision is needed. should (if a volunteer for a patch > exists) every little "save one statement in your code helper" be > added? Because there are thousands of them, and if you add them all > the readability of code will go down, because you need to first learn > them all. I think the answer to your question is a clear and loud "NO". The argument that we can refrain from using these new features does not hold, because other people will be using it, and we will have to know all of it to be able to understand their code. None of these features will automagically make Object Pascal a popular language. However, I seem to be one of the very few thinking this given the enthousiasm with which people are discussing this.

For what it's worth, I agree with you. It's one thing restoring something like the "inline if" (or a functional equivalent) which was in ALGOL and is regularly used in most current languages, but doing something like adding a completely new flow control construct which has no significant precedent in other languages is much more difficult to defend.

Soon I will be forced to emigrate to Javascript country. Despite all its drawbacks, it remains at least a simple language. a dozen keywords and you're done. No wonder Node.js is so popular. Compare that with the jungle we're making of it... :(

At the same time, I think it's worth distinguishing three distinct cases that contribute to syntax complexity.

The first is the case that you had in early ALGOL implementations, where there was limited support for external libraries and where every detail of control of- for example- file open mode had to be expressed as part of the language syntax.

The second is the case where a language has a fairly verbose syntax, but where this is used to define a rich set of general-purpose flow-control and data-definition constructs. This is where Pascal is at.

The third case is modern C++, Javascript and so on which grossly overload the limited ASCII character set and where abusing even the lowly parenthesis can have non-obvious effects. Then there's the issues they have with things like "static", and their use of "std::something" as quasi-directives.

I'm still struggling with a mainframe emulator, originally written in Javascript, where around half of the complexity was due to the lack of any support for multithreading. I also think that the recent forking of the Scratch graphical language, where a significant proportion of the community has rejected MIT's attempts to reimplement it in Javascript, indicates that there's an increasing awareness that both the language and its typical implementations- i.e. embedded in a browser or as ActionScript in Flash- leave much to be desired.

And Node.js is lipstick on a pig.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Walter Prins
to Martin Schreiber: We are at least two people. :-) Or to MSElang? ;-) Martin
Martin Schreiber wrote 7 lines
On Tuesday 13 October 2015 23:25:03 Michael Van Canneyt wrote: > However, I seem to be one of the very few thinking this given the > enthousiasm with which people are discussing this. > We are at least two people. :-)

For what it's worth, with me that's at least 3.

> Soon I will be forced to emigrate to Javascript country. Or to MSElang? ;-)

Or Scala? :-P (Digressing a bit more in this vein, I've been feeling the pull of more functional languages lately, in particular Scala, which if you don't know is a functional OO hybrid language that targets the JVM. I actually wish something similar happened in the Object Pascal space. C# inspired F#. Java inspired Scala. Delphi/FPC inspired/inspires ...? Further aside, for those interested in more functional programming and Scala, watch this video: https://goo.gl/chdMlv In a different vein, there's also the Rust language which is another language seems well worth learning and brings new ideas to the table well above and beyond syntactic sugar.... But enough of that, hope that's not been too off topic!)

Walter

Reply by email

Nikolai Zhubr
to Walter Prins

Hi all,
14.10.2015 23:44, Walter Prins:

Show quoted text 13 lines
On 14 October 2015 at 07:28, Martin Schreiber < > wrote: On Tuesday 13 October 2015 23:25:03 Michael Van Canneyt wrote: > However, I seem to be one of the very few thinking this given the > enthousiasm with which people are discussing this. > We are at least two people. :-) For what it's worth, with me that's at least 3.

Me too! Me too!
That's 4 already :-)

Thank you,
Nikolai

Reply by email