Discussion:
[std-proposals] please discontinue the command of the [while] and [do,while]
y***@gmail.com
6 years ago
Permalink
hello.

do you think my title?
i think to big problem.
[while] and [do,while] is so very easy use as brainless.
beginner programmer is soft fealing to use the [while] to make crazy ruin
program.

if no [while] and no [do,while] to no problem.
we have [for] command.

why i say?

my recent day.
i think to halting problem.
i say "can all programmer the parfect clear the halting problem."
so halting problem is scale to all problems.
any product needing ending sequence.

this problem is as in your fealing.

do you know plastic problem.
plastic is make by industry parsons.
this is not think for halting.
nature don't know how to halting for plastics.
now sea have plastics pollution problems.

it is halting problem.
again any product needing ending sequence.

i think to [for] is best! for as thinking to lifecycle.
think to lifecycle is difficalt than use [while].
but lifecycle is great thing for any product.
it as you and me.

do you think this problem.

thank you.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8c5cefbc-3565-4add-ae37-37d730e853c9%40isocpp.org.
k***@gmail.com
6 years ago
Permalink
You ain't from around these parts, are you?
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a62eab7c-d726-467f-9bf2-d4179b2dfc16%40isocpp.org.
David Brown
6 years ago
Permalink
This is an international mailing list. /Everyone/ is from around "these
parts", excluding Martians.

What you are trying to say is that the poster's command of English is so
bad, that the post is barely comprehensible. He (or she) should try
again, after getting help with translation from his native language.
Even google translate would help here.
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pruoh8%24tsl%241%40blaine.gmane.org.
Cleiton Santoia
6 years ago
Permalink
Hello,

I didnÂŽt get what you are trying to say, but when [for] loops and [while]
loops are compiled in assembly, the same set of instructions will be used
for both, as you can see in https://godbolt.org/z/sRiNoV, the lines 8-16
are equal to 20-28 ( only jump addressees are different )...

So, any "generalization of halting problem" would affect both in the same
way.

I hope that helped
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d9dcf859-5171-419e-8502-3e8ac26322d7%40isocpp.org.
y***@gmail.com
6 years ago
Permalink
thank you for your help.
i need more study.
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6c864d58-0972-4098-8b6f-7059af02b1c6%40isocpp.org.
Vinnie Falco
6 years ago
Permalink
So removing the 'while'
Taking this to its logical absurd conclusion we could remove the following:

break,
case
continue,
else
for,
switch
while
?

And replace them with:

goto

Regards
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0c89963c-d5e4-49f2-a460-fb987ec5a50a%40isocpp.org.
Klaim - Joël Lamotte
6 years ago
Permalink
My understanding is that the initial point is that a for loop is
finite but a while loop is not, which basically mean you never get the
halting problem with for loops.
That's totally wrong in C++ at least, but that's my understanding.

A. Joël Lamotte
Post by Vinnie Falco
So removing the 'while'
break,
case
continue,
else
for,
switch
while
?
goto
Regards
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0c89963c-d5e4-49f2-a460-fb987ec5a50a%40isocpp.org.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91ONMjey1H8bznGzAWCkCfEutatKXdmm0sa%2BC5H8%3DJ4q3bQ%40mail.gmail.com.
m***@gmail.com
6 years ago
Permalink
I agree that's what they are trying to convey, but it's not a good
suggestion.

Plenty of applications (such as games) want to run in an infinite loop
until an explicit break condition (such as pressing the quit button) is met.
Other applications (such as computers on rockets) never want to exit, they
aim to run forever.

Trying to remove infinite loops from c++ in order to be able to prove a
program can complete means these things can't be written in c++.

If OP works in a domain where proving these things is important, then c++
might not be the language for them.
Post by Klaim - Joël Lamotte
My understanding is that the initial point is that a for loop is
finite but a while loop is not, which basically mean you never get the
halting problem with for loops.
That's totally wrong in C++ at least, but that's my understanding.
A. Joël Lamotte
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/94ffcfd5-0657-4632-95d9-efc88208a8d6%40isocpp.org.
Vinnie Falco
6 years ago
Permalink
Trying to remove infinite loops from c++ in order to be able to prove a program
can complete means these things can't be written in c++.
This is a non-turing-complete language for which the halting problem
is solvable:

"Simplicity: A New Language for Blockchains"
Simplicity is a typed, combinator-based, functional language without
loops and recursion, designed to be used for crypto-currencies and
blockchain applications.
<https://blockstream.com/simplicity.pdf>

Regards
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BEzHGdvL2k3CS%2BoeC7e8fmviEVj7PD2OLQiBEJLTf2QZMqUWA%40mail.gmail.com.
FrankHB1989
6 years ago
Permalink
圚 2018幎11月8日星期四 UTC+8䞊午10:56:55Vinnie Falco写道
...
This might be interesting (esp. the formal methods and the part of TCO to
me, compared to the disability of EVM), but does it target the domains
sufficiently close to C++ concerned here?

In fact, every language with proved strong normalization in rewriting
semantics is non-Turing-complete like this. And this is far from C++, even
far than well-reserarched STLC
<https://en.wikipedia.org/wiki/Simply_typed_lambda_calculus>, which is
enough to show the property.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/987a5677-b6fd-46d0-8655-6e5c582a136a%40isocpp.org.
Vinnie Falco
6 years ago
Permalink
Post by FrankHB1989
This might be interesting (esp. the formal methods and the part of TCO to
me, compared to the disability of EVM), but does it target the domains
sufficiently close to C++ concerned here?
Good question. I linked this particular paper because I am a fan of the
work of the bitcoin core developers. The paper has some very nice novel
ideas. It would be nice if one of them would give a talk at Cppcon on C++
techniques in decentralized systems, the C++ Alliance might help sponsor
the talk (http://cpp.al)

Thanks
--
Follow me on GitHub: https://github.com/vinniefalco
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BEzHGeaC9pHH8ArUV81yC3uvgGCUeFbucLTi0Q8WKMYyvEV0w%40mail.gmail.com.
y***@gmail.com
6 years ago
Permalink
yes. you good.

thank you for your opnion.
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1b1bb835-3a9e-4e68-8e4e-5ec957e38e70%40isocpp.org.
y***@gmail.com
6 years ago
Permalink
maybe you use the [for] timing to think the halting.
it is 0 or 1 problem.
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/06909c10-a77f-4ab5-b82a-85a206b29628%40isocpp.org.
Richard Hodges
6 years ago
Permalink
Post by Vinnie Falco
So removing the 'while'
break,
case
continue,
else
for,
switch
while
?
goto
For further improvements in coding efficiency, we could go further:

add these:
- blt - branch if less than zero
- bgt - branch if greater than zero
- bz - branch if zero
- b - branch always

remove these:
- if
- goto
...
--
Richard Hodges
***@gmail.com
office: +442032898513
home: +376841522
mobile: +376380212 (this will be *expensive* outside Andorra!)
skype: madmongo
facebook: hodges.r
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3haiCekoYHAPXzB7Y%2B1nnZOEB8fBnoi5T6M5Y3-u0WVbwA%40mail.gmail.com.
y***@gmail.com
6 years ago
Permalink
do you need spaghetii?
Post by Vinnie Falco
So removing the 'while'
break,
case
continue,
else
for,
switch
while
?
goto
Regards
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/594f24e8-7228-4b19-82a9-800f77911e98%40isocpp.org.
FrankHB1989
6 years ago
Permalink
...
I would guess... but what do you mean about "industry parsons"?

Thanks to the redundant information in the (whatever) natural language you
use, I probably can know what you are talking about. But seriously, no.
Even allowing to modify the current rules in the language, "for" does
hardly be qualified as a primitive for a general-purposed language. It can
be combined neatly if there are more sane candidates. For now, it has to be
for compatibility, so it deserved to be preserved.

Actually, I feel there are more insanity in do-while. I avoid raw do-while
totally with a saner construct
<https://bitbucket.org/FrankHB/yslib/src/4ed6f283887b299b36896e9438674eab61008ffa/YBase/include/ystdex/functional.hpp#functional.hpp-1052>
as the replacement in my code. (There does exist only one exception: the
do-while idiom in macros.) But that's not combined by primitives - the
basic building blocks expose the ability to manipulate the *control effects*
as these operators. It is just hiding the unpleasant part.

The unpleasant effects mostly come from the lack of (meta) operations work
around the scoping rules. The technique above is available in pure C++
because it is just occasionally allowed by the historical design of the
language and its ancestors (notably, traditional C). But that's far not
enough to my flavor. I have to be more *Lispy* to get a bunch of control
operators, but most of them seems hopeless in C++ (even without the
possibility of the notion on *operators*). For example, I want letrec
<https://en.wikipedia.org/wiki/Lambda_calculus#Named_constants>. Will it be
available in C++? *Very unlikely*, as I think. I don't expect C++ will
accept bare-metal design without foundation from user experience.

But why bother? The language does the things better than others. When it
does not serve to my requirement enough, I just roll my own wheels. That's
not desperately difficult. I can implement these control operators in far
more elegant ways despite the underlying QoI issues, like this
<https://bitbucket.org/FrankHB/yslib/src/4ed6f283887b/YFramework/source/NPL/Dependency.cpp#Dependency.cpp-681>
(for who may be interested: compare this succinct definition to lengthy
formal macro-expansion magic stuff in RnRS Scheme and think about the
reasons of the complexity).

BTW, as of my flavor of control primitives, I would only bless very a few:
if ... and possible call/cc. Even semicolon is not qualified to have the
control effect to be a primitive. There do exist other non-control ones,
but at least not awful implicit sequenced-in-body lambda like Scheme. (I'm
not kidding; almost all others are formally neatly implementable. This
<https://en.wikipedia.org/wiki/Engine_(computer_science)>would be a
probable exception, but I don't think you will be interested in similar
more estoric constructs. And I'd admit call/cc may be fit natural language
processing in my brain better than all "primitives" mentioned here.)
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40d891e4-5449-461b-b75c-e653eb9b494f%40isocpp.org.
Raymund Hofmann
6 years ago
Permalink
No, its the evil goto that has to be banned. And then concurrency. And
global variables. Functions too, infinite recursion is always lurking. Best
to ban all abstractions, they are the root of all evil.

Oh wait, what about banning stupidity?
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD_7Vbke5Y-2kOaWuXSLMGTqdycPTQkKqEzaoGsL6ZGkeCp-1A%40mail.gmail.com.
Hyman Rosen
6 years ago
Permalink
Post by Raymund Hofmann
No, its the evil goto that has to be banned. And then concurrency. And
global variables. Functions too, infinite recursion is always lurking. Best
to ban all abstractions, they are the root of all evil.
Oh wait, what about banning stupidity?
Banning the object model would be great.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdahwvWVqOi5fv%2B4Q%3DeGpaAEF-Kathg6SEu2jeFuiKOkuw%40mail.gmail.com.
y***@gmail.com
6 years ago
Permalink
hahaha.it is good.
i think to can some usage the object model able to exclution.
Post by Hyman Rosen
Post by Raymund Hofmann
No, its the evil goto that has to be banned. And then concurrency. And
global variables. Functions too, infinite recursion is always lurking. Best
to ban all abstractions, they are the root of all evil.
Oh wait, what about banning stupidity?
Banning the object model would be great.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8a9412d9-32f1-4ab1-83c5-661ddd1159b6%40isocpp.org.
Jake Arkinstall
6 years ago
Permalink
"Lifecycle is a great thing for any product"

So if an ECG monitor halts, that's a good thing? If a server terminates
when a single request is made, that's a good thing?

Halting isn't always a good thing.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO1Pr%2BYUA15Ms4yEQpotAFmqeXJe-eE1AAa71HScXyTWg%40mail.gmail.com.
y***@gmail.com
6 years ago
Permalink
hello.

i suprised to you.
is truely ECG moniter not have halting?
i wonder that.

do you ECG moniter use timing to not decision the lifecycle?
if it time the new thing.but you ever see old thing to without lifecycle.
i wonder that.

promise is promise.

thank you.
Post by Jake Arkinstall
"Lifecycle is a great thing for any product"
So if an ECG monitor halts, that's a good thing? If a server terminates
when a single request is made, that's a good thing?
Halting isn't always a good thing.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6e54b1da-dc18-426b-b4b6-5fb2436169a5%40isocpp.org.
y***@gmail.com
6 years ago
Permalink
yes.begenner programmer use to easy make ruin.
need some protection or discontinue.so i think.
...
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/20406696-5b54-4040-b34f-0ef374a7fd8f%40isocpp.org.
Loading...