Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #53464 > unrolled thread
| Started by | Rosario193 <Rosario@invalid.invalid> |
|---|---|
| First post | 2014-11-26 21:54 +0100 |
| Last post | 2014-12-19 02:34 +0100 |
| Articles | 20 on this page of 177 — 31 participants |
Back to article view | Back to comp.lang.c
the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:54 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-26 21:56 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:45 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:52 +0100
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-01 23:25 -0500
Re: the language "Bill Cunningham" <nospam@nspam.invalid> - 2014-12-02 00:56 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-04 14:52 +0100
Re: the language "Osmium" <r124c4u102@comcast.net> - 2014-12-04 08:07 -0600
Re: the language Geoff <geoff@invalid.invalid> - 2014-12-04 10:20 -0800
Re: the language Mark Storkamp <mstorkamp@yahoo.com> - 2014-11-26 15:11 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:16 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:18 +0100
Re: the language John Bode <jfbode1029@gmail.com> - 2014-11-26 13:12 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-27 00:37 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-11-27 01:13 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-11-26 22:45 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 07:41 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-27 08:12 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-27 01:43 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 11:56 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 09:08 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 20:58 +0100
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-11-28 19:22 -0600
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-02 02:59 +0100
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 02:53 +0000
Re: the language Les Cargill <lcargill99@comcast.com> - 2014-12-01 21:25 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-02 06:22 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-27 08:37 +0000
Re: the language Reinhardt Behm <rbehm@hushmail.com> - 2014-11-27 16:44 +0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-27 15:35 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-27 11:58 -0500
Re: the language jt@toerring.de (Jens Thoms Toerring) - 2014-11-27 22:44 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 09:52 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 12:53 -0800
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 10:07 +0100
Re: the language Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-11-28 14:57 +0100
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:09 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:01 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 14:46 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-11-28 13:16 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-11-28 22:09 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:40 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 14:42 -0800
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:22 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-11-28 23:09 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-28 16:14 -0800
Re: the language BartC <bc@freeuk.com> - 2014-11-29 01:42 +0000
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-11-29 01:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-11-29 04:03 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-01 00:55 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-02 05:42 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-11-28 19:25 -0500
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-01 03:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-01 14:02 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-05 10:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 08:25 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 10:44 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-07 19:17 +0000
Re: the language Öö Tiib <ootiib@hot.ee> - 2014-12-07 15:48 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 05:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:27 -0800
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-08 06:00 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 06:17 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-08 03:37 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-08 12:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 04:21 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-16 12:43 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-16 14:46 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 00:23 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-17 07:01 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 07:22 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-17 11:56 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-17 05:43 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:30 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:41 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 14:34 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 02:15 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-17 22:31 -0500
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:19 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 07:52 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-18 17:21 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:15 +0000
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 01:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 07:48 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 07:40 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 12:54 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 09:54 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 15:19 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:00 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:13 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 11:27 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 16:45 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:48 -0500
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 19:10 +0000
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:17 -0600
Re: the language Morris Dovey <mrdovey@iedu.com> - 2014-12-19 21:32 -0600
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 16:49 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:00 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-19 13:57 -0500
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 14:31 -0800
Re: the language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-19 20:29 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 20:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-17 07:18 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-17 15:45 +0000
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-17 16:50 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-17 17:24 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-18 02:07 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 12:04 +0000
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-18 08:06 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-18 08:30 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 00:11 -0500
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-19 07:00 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-19 08:43 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-19 23:29 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 00:37 -0800
Re: the language gazelle@shell.xmission.com (Kenny McCormack) - 2014-12-20 08:45 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-20 09:45 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-20 03:17 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-18 06:09 -0800
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:30 +0000
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-18 14:23 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-18 08:18 -0800
Re: the language Richard Damon <Richard@Damon-Family.org> - 2014-12-20 12:22 -0500
Re: the language James Kuyper <jameskuyper@verizon.net> - 2014-12-20 13:36 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:43 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-20 11:37 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:10 +0000
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:02 -0600
Re: the language Kaz Kylheku <kaz@kylheku.com> - 2014-12-21 22:02 +0000
Re: the language Stephen Sprunk <stephen@sprunk.org> - 2014-12-21 23:49 -0600
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-21 17:45 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:29 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-20 05:29 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:32 -0800
Re: the language Robert Wessel <robertwessel2@yahoo.com> - 2014-12-21 15:23 -0600
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-22 23:39 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-20 20:22 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-18 10:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:36 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-19 09:24 -0800
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 17:53 +0000
Re: the language Tim Rentsch <txr@alumni.caltech.edu> - 2014-12-20 11:48 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 02:20 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 08:31 +0000
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-19 09:31 +0000
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-19 10:10 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-19 07:08 -0800
Re: the language JohnF <john@please.see.sig.for.email.com> - 2014-12-20 06:39 +0000
Re: the language John Forkosh <forkosh@panix.com> - 2014-12-20 07:32 +0000
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 17:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-04 12:40 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-04 18:02 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 09:47 -0500
Re: the language Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-05 15:14 +0000
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-05 08:42 -0800
Re: the language glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-06 00:14 +0000
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:19 -0500
Re: the language Richard Damon <Richard@Damon-Family.org> - 2015-01-04 15:59 -0500
Re: the language Keith Thompson <kst-u@mib.org> - 2015-01-04 14:30 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-04 15:44 -0800
Re: the language James Kuyper <jameskuyper@verizon.net> - 2015-01-05 13:36 -0500
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-11-28 12:07 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-02 23:16 +0100
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-03 02:23 -0800
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-03 15:55 +0100
Re: the language Nobody <nobody@nowhere.invalid> - 2014-12-03 15:42 +0000
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 04:49 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 09:07 -0800
Re: the language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-04 10:08 -0800
Re: the language Keith Thompson <kst-u@mib.org> - 2014-12-04 11:49 -0800
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-05 12:32 +0100
Re: the language raltbos@xs4all.nl (Richard Bos) - 2014-12-04 22:17 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 18:17 +0100
Re: the language Richard Heathfield <invalid@see.sig.invalid> - 2014-12-18 18:12 +0000
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:15 +0100
Re: the language Rosario193 <Rosario@invalid.invalid> - 2014-12-18 23:50 +0100
Re: the language "ocq (an evil corporate man)" <ocq@maili.ng> - 2014-12-19 02:34 +0100
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-11-28 22:09 +0000 |
| Message-ID | <m5arq0$7hg$1@news.xmission.com> |
| In reply to | #53622 |
In article <kfnbnnrt49d.fsf@x-alumni2.alumni.caltech.edu>, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Richard Heathfield <invalid@see.sig.invalid> writes: > >> Rosario193 wrote: >> >>> one language for program has to have no undefinite behaviour >>> and has to be simple...the one that program has to think to the >>> problem one want resolve more than language laws etc >> >> It turns out to be surprisingly difficult to design a language >> that has both of the following characteristics: >> >> (a) has no undefined behaviour; >> (b) is sufficiently powerful to be interesting. >> >> [snip elaboration] > >Either what you mean is different from what it appears you >are saying, or the claim is, well, let's say wrong in the >high-order bit. An ordinary deterministic Turing machine >(ie, as a class of programs) satisfies both properties. Objection. (b) is subjective, so one can always claim that whatever is put forward fails that test. I, for one, think your example fails requirement (b). -- (The Republican mind, in a nutshell) You believe things that are incomprehensible, inconsistent, impossible because we have commanded you to believe them; go then and do what is unjust because we command it. Such people show admirable reasoning. Truly, whoever is able to make you absurd is able to make you unjust. If the God-given understanding of your mind does not resist a demand to believe what is impossible, then you will not resist a demand to do wrong to that God-given sense of justice in your heart. As soon as one faculty of your soul has been dominated, other faculties will follow as well. And from this derives all those crimes of religion which have overrun the world. (Alternative condensed translation) "Those who can make you believe absurdities, can make you commit atrocities".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-01 03:40 -0800 |
| Message-ID | <kfnr3wjsing.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53624 |
gazelle@shell.xmission.com (Kenny McCormack) writes: > In article <kfnbnnrt49d.fsf@x-alumni2.alumni.caltech.edu>, > Tim Rentsch <txr@alumni.caltech.edu> wrote: >>Richard Heathfield <invalid@see.sig.invalid> writes: >> >>> Rosario193 wrote: >>> >>>> one language for program has to have no undefinite behaviour >>>> and has to be simple...the one that program has to think to the >>>> problem one want resolve more than language laws etc >>> >>> It turns out to be surprisingly difficult to design a language >>> that has both of the following characteristics: >>> >>> (a) has no undefined behaviour; >>> (b) is sufficiently powerful to be interesting. >>> >>> [snip elaboration] >> >> Either what you mean is different from what it appears you >> are saying, or the claim is, well, let's say wrong in the >> high-order bit. An ordinary deterministic Turing machine >> (ie, as a class of programs) satisfies both properties. > > Objection. (b) is subjective, so one can always claim that > whatever is put forward fails that test. [snip elaboration] Yes, it's because of this kind of weaseling that I put in the clause "Either what you mean is different from ...". I offer no opinion on an arbitrary subjective interpretation of the stated criteria.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-11-28 14:42 -0800 |
| Message-ID | <908aaab1-0841-40c9-b1a6-4fe17da1aba7@googlegroups.com> |
| In reply to | #53622 |
On Friday, November 28, 2014 9:16:38 PM UTC, Tim Rentsch wrote: > > > It turns out to be surprisingly difficult to design a language > > that has both of the following characteristics: > > > > (a) has no undefined behaviour; > > (b) is sufficiently powerful to be interesting. > > > > [snip elaboration] > > Either what you mean is different from what it appears you > are saying, or the claim is, well, let's say wrong in the > high-order bit. An ordinary deterministic Turing machine > (ie, as a class of programs) satisfies both properties. > Power doesn't mean "can theoretically support a program" but "is easy for human programmer / human-designed automatic systems to implement and verify such a program in".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-01 03:22 -0800 |
| Message-ID | <kfnvblvsjgt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53627 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, November 28, 2014 9:16:38 PM UTC, Tim Rentsch wrote: >> >> > It turns out to be surprisingly difficult to design a language >> > that has both of the following characteristics: >> > >> > (a) has no undefined behaviour; >> > (b) is sufficiently powerful to be interesting. >> > >> > [snip elaboration] >> >> Either what you mean is different from what it appears you >> are saying, or the claim is, well, let's say wrong in the >> high-order bit. An ordinary deterministic Turing machine >> (ie, as a class of programs) satisfies both properties. >> > Power doesn't mean "can theoretically support a program" but > "is easy for human programmer / human-designed automatic systems > to implement and verify such a program in". You are confusing your opinion with fact.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-11-28 23:09 +0000 |
| Message-ID | <Rg7ew.1962$Z51.89@fx47.am4> |
| In reply to | #53622 |
Tim Rentsch wrote: > Richard Heathfield <invalid@see.sig.invalid> writes: > >> Rosario193 wrote: >> >>> one language for program has to have no undefinite behaviour >>> and has to be simple...the one that program has to think to the >>> problem one want resolve more than language laws etc >> >> It turns out to be surprisingly difficult to design a language >> that has both of the following characteristics: >> >> (a) has no undefined behaviour; >> (b) is sufficiently powerful to be interesting. >> >> [snip elaboration] > > Either what you mean is different from what it appears you > are saying, or the claim is, well, let's say wrong in the > high-order bit. An ordinary deterministic Turing machine > (ie, as a class of programs) satisfies both properties. A Turing machine is interesting in an academic sense, but not in the sense that I intended. To be interesting, a computer has to be able to sing and dance, not just hack away at the Halting Problem or take a month to calculate the square root of 17. This requires the support of the language, or at least it requires the language not to get in the way. Let us consider as an example a specific address: 0xDEADBEEF. I'm going to use C as my langue de preference, but any (sufficiently powerful) language would have done. unsigned char *p = (unsigned char *)0xDEADBEEF; *p = 42; Right, what does this do? In C, the conversion to unsigned char * is legal (6.3.2.3(5) of C99), and the result is implementation-defined. The sticky part comes next. From 6.5.3.2(4) of C99: The unary * operator denotes indirection. If the operand points to a function, the result is a function designator; if it points to an object, the result is an lvalue designating the object. If the operand has type ``pointer to type'', the result has type ``type''. If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. So if 0xDEADBEEF happens to be the address of an object, the behaviour is reasonably well-defined (it's conceivable that the assignment of that particular bit pattern to that particular byte in that particular object yields a trap representation, but let's not worry about that just now). But if the address is 'invalid', then the behaviour is undefined. Now let's look at the interesting things we can do with this assignment: a) On the DeathStation 9000, 0xDEADBEEF is the address that you need to load with the number of missiles you want to launch. b) On the LifeStation 0009, 0xDEADBEEF is part of video RAM, and this is how you write a dollar sign to a particular place on the screen (and before you check, no, the LifeStation 0009 doesn't use ASCII; if it did, an asterisk would be written, of course). c) On the Limbo 64, the assignment reboots the machine (by design). d) On the Zen GT, the assignment limits the engine speed to 42 kilorevolutions per minute. And so on, to the limit of your imagination. If C tried to define the behaviour of the construct, it would have to be either well-defined (go on, have a go), or unspecified (in which case the Standard would have to explain and thus limit the possible range of behaviours), or implementation-defined (see 'unspecified', but add compiler docs). Any of these choices would arbitrarily curtail the scope that C has to deal with quirky hardware. It remains my contention that undefined behaviour is an essential part of any sufficiently powerful language. To define every behaviour is to design a closed-in language that arbitrarily restricts us to solving problems of the kind that the language designer envisaged. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-11-28 16:14 -0800 |
| Message-ID | <ab7e14b1-9b3b-435d-8cbc-ac701666f6f2@googlegroups.com> |
| In reply to | #53629 |
On Friday, November 28, 2014 11:09:45 PM UTC, Richard Heathfield wrote: > > It remains my contention that undefined behaviour is an essential > part of any sufficiently powerful language. To define every behaviour > is to design a closed-in language that arbitrarily restricts us to > solving problems of the kind that the language designer envisaged. > A function, in the mathematical sense, in a mapping of an input set to an output set. So in digital computer terms, you call a function with bits set to one state, you get back bit set in another state. I call these "bit shuffling" functions. However a computer that just shuffles bits about is useless, a computer with a very impoverished IO, such as stdin / stdout, isn't very useful unless connected to another computer with a richer set of IO which can drive it. So as well as bit-shuffling functions, you need subroutines which do thing, that take physical actions in the real world. I call these procedures, because in normal English usage a procedure is a series of actions taken in accordance with a protocol. Programming bit shuffling functions and programming procedures is a different type of programming. A real programmer will often do both, for example today I wrote a function to do positivity-retaining interpolation of values (a bit shuffler), and a routine to allow the user to dynamically adjust a colour scale with the mouse (a procedure).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-11-29 01:42 +0000 |
| Message-ID | <kw9ew.9471$mp2.6210@fx01.am4> |
| In reply to | #53635 |
On 29/11/2014 00:14, Malcolm McLean wrote: > However a computer that just shuffles bits about is useless But that's not possible except in theory. A real computer will have a way of getting a program (and some data) into memory, and a Start or Run button. So it will have input. Then if you allow the luxury of a Stop, Halt or Exit statement, then certain useful tasks can be done. Measuring how long an algorithm takes to complete, for example. (And if the memory can be manually examined afterwards, then that will do for output, and a lot more things become possible. The first computer I built was exactly like this.) Without a Stop function within the program (there will be a way of stopping it physically), a computer might still generate radio interference, heat, or even noise. Not necessarily useless, although that might require some imagination to make use of. (For example, with a program to play a tune when the RF emissions are picked up on a nearby FM radio. As it happens, this was one method I used to find out what my circuit was up to!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-11-29 01:42 +0000 |
| Message-ID | <20141128174155.46@kylheku.com> |
| In reply to | #53635 |
On 2014-11-29, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Friday, November 28, 2014 11:09:45 PM UTC, Richard Heathfield wrote: >> >> It remains my contention that undefined behaviour is an essential >> part of any sufficiently powerful language. To define every behaviour >> is to design a closed-in language that arbitrarily restricts us to >> solving problems of the kind that the language designer envisaged. >> > A function, in the mathematical sense, in a mapping of an input set > to an output set. So in digital computer terms, you call a function > with bits set to one state, you get back bit set in another state. > I call these "bit shuffling" functions. It's only shuffling if you get back the same size bit vector, where the number of 1's is the same as in the original. Otherwise, formally speaking, it is bit munging.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-11-29 04:03 -0800 |
| Message-ID | <c8fc088f-0bca-45fc-a1a5-6839c3423de7@googlegroups.com> |
| In reply to | #53640 |
On Saturday, November 29, 2014 1:42:58 AM UTC, Kaz Kylheku wrote: > > > A function, in the mathematical sense, in a mapping of an input set > > to an output set. So in digital computer terms, you call a function > > with bits set to one state, you get back bit set in another state. > > I call these "bit shuffling" functions. > > It's only shuffling if you get back the same size bit vector, > where the number of 1's is the same as in the original. > Otherwise, formally speaking, it is bit munging. > Technically you're right. Also someone pointed out that "shuffle" is not a bit-shuffling function. But people objected to my using the plain term "function", because C programmers, though not the C language, mis-use it for "subroutine".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-01 00:55 -0800 |
| Message-ID | <lniohvrbpf.fsf@nuthaus.mib.org> |
| In reply to | #53635 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> However a computer that just shuffles bits about is useless, a computer
> with a very impoverished IO, such as stdin / stdout, isn't very useful
> unless connected to another computer with a richer set of IO which
> can drive it. So as well as bit-shuffling functions, you need subroutines
> which do thing, that take physical actions in the real world. I call
> these procedures, because in normal English usage a procedure is a
> series of actions taken in accordance with a protocol.
I'm going to call subroutines that return results that are computed
from their arguments and nothing else, and that have no side effects,
"integer functions", since they can be considered to deal only
with mathematical integers. I'm going to call subroutines that
have side effects, including input and output, "real functions",
because they interact with the real world.
Oh, wait, no I'm not, because those phrases *already have accepted
meanings that are inconsistent with what I just described.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-12-02 05:42 +0000 |
| Message-ID | <m5jjg0$rp0$3@speranza.aioe.org> |
| In reply to | #53689 |
Keith Thompson <kst-u@mib.org> wrote: (snip) > I'm going to call subroutines that return results that are computed > from their arguments and nothing else, and that have no side effects, > "integer functions", since they can be considered to deal only > with mathematical integers. I'm going to call subroutines that > have side effects, including input and output, "real functions", > because they interact with the real world. > Oh, wait, no I'm not, because those phrases *already have accepted > meanings that are inconsistent with what I just described. At some point, things can get confusing between the meaning of terms in each language, and the sometimes different meaning for the same terms in CS, EE, or math. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-11-28 19:25 -0500 |
| Message-ID | <ho8ew.154248$O76.54524@fx15.iad> |
| In reply to | #53629 |
On 11/28/14, 6:09 PM, Richard Heathfield wrote: > Tim Rentsch wrote: > >> Richard Heathfield <invalid@see.sig.invalid> writes: >> >>> Rosario193 wrote: >>> >>>> one language for program has to have no undefinite behaviour >>>> and has to be simple...the one that program has to think to the >>>> problem one want resolve more than language laws etc >>> >>> It turns out to be surprisingly difficult to design a language >>> that has both of the following characteristics: >>> >>> (a) has no undefined behaviour; >>> (b) is sufficiently powerful to be interesting. >>> >>> [snip elaboration] >> >> Either what you mean is different from what it appears you >> are saying, or the claim is, well, let's say wrong in the >> high-order bit. An ordinary deterministic Turing machine >> (ie, as a class of programs) satisfies both properties. > > A Turing machine is interesting in an academic sense, but not in the sense > that I intended. To be interesting, a computer has to be able to sing and > dance, not just hack away at the Halting Problem or take a month to > calculate the square root of 17. This requires the support of the language, > or at least it requires the language not to get in the way. > > Let us consider as an example a specific address: 0xDEADBEEF. I'm going to > use C as my langue de preference, but any (sufficiently powerful) language > would have done. > > unsigned char *p = (unsigned char *)0xDEADBEEF; > *p = 42; > > Right, what does this do? > > In C, the conversion to unsigned char * is legal (6.3.2.3(5) of C99), and > the result is implementation-defined. The sticky part comes next. > > From 6.5.3.2(4) of C99: > The unary * operator denotes indirection. If the operand points to a > function, the result is a function designator; if it points to an object, > the result is an lvalue designating the object. If the operand has type > ``pointer to type'', the result has type ``type''. If an invalid value has > been assigned to the pointer, the behavior of the unary * operator is > undefined. > > So if 0xDEADBEEF happens to be the address of an object, the behaviour is > reasonably well-defined (it's conceivable that the assignment of that > particular bit pattern to that particular byte in that particular object > yields a trap representation, but let's not worry about that just now). > > But if the address is 'invalid', then the behaviour is undefined. > > Now let's look at the interesting things we can do with this assignment: > > a) On the DeathStation 9000, 0xDEADBEEF is the address that you need to load > with the number of missiles you want to launch. > b) On the LifeStation 0009, 0xDEADBEEF is part of video RAM, and this is how > you write a dollar sign to a particular place on the screen (and before you > check, no, the LifeStation 0009 doesn't use ASCII; if it did, an asterisk > would be written, of course). > c) On the Limbo 64, the assignment reboots the machine (by design). > d) On the Zen GT, the assignment limits the engine speed to 42 > kilorevolutions per minute. > > And so on, to the limit of your imagination. > > If C tried to define the behaviour of the construct, it would have to be > either well-defined (go on, have a go), or unspecified (in which case the > Standard would have to explain and thus limit the possible range of > behaviours), or implementation-defined (see 'unspecified', but add compiler > docs). > > Any of these choices would arbitrarily curtail the scope that C has to deal > with quirky hardware. > > It remains my contention that undefined behaviour is an essential part of > any sufficiently powerful language. To define every behaviour is to design a > closed-in language that arbitrarily restricts us to solving problems of the > kind that the language designer envisaged. > And I would contend otherwise. Yes, the operation of converting an arbitrary integer into a pointer is going to (generally) yield undefined behavior, and any language that want to total prohibit undefined behavior needs to prohibit this operation. This doesn't mean that you can't provide some implementation provide "bits" (maybe functions, maybe values) that define how to get access to various "system" objects. Yes, if you are going to define your requirements that says that the only thing you are allowed to do are things that are "Globally standard defined", and that the implementation can't add ANY defined behavior, then of course, the only capabilities are things that you can demand that every implementation provide (which can still be a reasonably large space but does exclude a number of actions).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-01 03:21 -0800 |
| Message-ID | <kfnzjb7sjhz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53629 |
Richard Heathfield <invalid@see.sig.invalid> writes: > Tim Rentsch wrote: > >> Richard Heathfield <invalid@see.sig.invalid> writes: >> >>> Rosario193 wrote: >>> >>>> one language for program has to have no undefinite behaviour >>>> and has to be simple...the one that program has to think to the >>>> problem one want resolve more than language laws etc >>> >>> It turns out to be surprisingly difficult to design a language >>> that has both of the following characteristics: >>> >>> (a) has no undefined behaviour; >>> (b) is sufficiently powerful to be interesting. >>> >>> [snip elaboration] >> >> Either what you mean is different from what it appears you >> are saying, or the claim is, well, let's say wrong in the >> high-order bit. An ordinary deterministic Turing machine >> (ie, as a class of programs) satisfies both properties. > > A Turing machine is interesting in an academic sense, but not in > the sense that I intended. To be interesting, a computer has to > be able to sing and dance, not just hack away at the Halting > Problem or take a month to calculate the square root of 17. > [snip elaboration] This falls under the category of meaning something different from what it appears is being said. In any case the claim is still wrong in the high-order bit, unless the words used are defined in some silly non-standard way to make it vacuously true.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-01 14:02 +0000 |
| Message-ID | <_x_ew.46881$066.7036@fx16.am4> |
| In reply to | #53695 |
Tim Rentsch wrote: > Richard Heathfield <invalid@see.sig.invalid> writes: > >> Tim Rentsch wrote: >> >>> Richard Heathfield <invalid@see.sig.invalid> writes: >>> >>>> Rosario193 wrote: >>>> >>>>> one language for program has to have no undefinite behaviour >>>>> and has to be simple...the one that program has to think to the >>>>> problem one want resolve more than language laws etc >>>> >>>> It turns out to be surprisingly difficult to design a language >>>> that has both of the following characteristics: >>>> >>>> (a) has no undefined behaviour; >>>> (b) is sufficiently powerful to be interesting. >>>> >>>> [snip elaboration] >>> >>> Either what you mean is different from what it appears you >>> are saying, or the claim is, well, let's say wrong in the >>> high-order bit. An ordinary deterministic Turing machine >>> (ie, as a class of programs) satisfies both properties. >> >> A Turing machine is interesting in an academic sense, but not in >> the sense that I intended. To be interesting, a computer has to >> be able to sing and dance, not just hack away at the Halting >> Problem or take a month to calculate the square root of 17. >> [snip elaboration] > > This falls under the category of meaning something different from > what it appears is being said. Perhaps, but I wasn't trying to be evasive. > In any case the claim is still > wrong in the high-order bit, unless the words used are defined > in some silly non-standard way to make it vacuously true. I disagree. Let's say we're trying to standardise the effect of poking a byte. Either we make it illegal (in which case we limit the power of the language), or we make it well-defined (in which case we limit the power of the computer), or we make it unspecified (in which case we limit the power of both), or we make it implementation-defined (in which case we limit the power of both, but we make the implementor write it down), or we leave it undefined (in which case we have the same situation that we do now). I don't see any other possibilities. Perhaps you could explain your reasoning more closely. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2014-12-05 10:18 -0800 |
| Message-ID | <kfnfvcuyn7h.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #53710 |
Richard Heathfield <invalid@see.sig.invalid> writes: > Tim Rentsch wrote: > >> Richard Heathfield <invalid@see.sig.invalid> writes: >> >>> Tim Rentsch wrote: >>> >>>> Richard Heathfield <invalid@see.sig.invalid> writes: >>>> >>>>> Rosario193 wrote: >>>>> >>>>>> one language for program has to have no undefinite behaviour >>>>>> and has to be simple...the one that program has to think to >>>>>> the problem one want resolve more than language laws etc >>>>> >>>>> It turns out to be surprisingly difficult to design a language >>>>> that has both of the following characteristics: >>>>> >>>>> (a) has no undefined behaviour; >>>>> (b) is sufficiently powerful to be interesting. >>>>> >>>>> [snip elaboration] >>>> >>>> Either what you mean is different from what it appears you >>>> are saying, or the claim is, well, let's say wrong in the >>>> high-order bit. An ordinary deterministic Turing machine >>>> (ie, as a class of programs) satisfies both properties. >>> >>> A Turing machine is interesting in an academic sense, but not in >>> the sense that I intended. To be interesting, a computer has to >>> be able to sing and dance, not just hack away at the Halting >>> Problem or take a month to calculate the square root of 17. >>> [snip elaboration] >> >> This falls under the category of meaning something different from >> what it appears is being said. > > Perhaps, but I wasn't trying to be evasive. I didn't mean to imply you were. My comment was neutral as to any underlying intention you may (or may not) have had. >> In any case the claim is still >> wrong in the high-order bit, unless the words used are defined >> in some silly non-standard way to make it vacuously true. > > I disagree. Let's say we're trying to standardise the effect of > poking a byte. Either we make it illegal (in which case we limit > the power of the language), or we make it well-defined (in which > case we limit the power of the computer), or we make it > unspecified (in which case we limit the power of both), or we > make it implementation-defined (in which case we limit the power > of both, but we make the implementor write it down), or we leave > it undefined (in which case we have the same situation that we do > now). > > I don't see any other possibilities. It sounds like what you are saying is that, in the absence of undefined behavior, then /by definition/ a language is not interesting (or that it is not sufficiently powerful to be interesting, which amounts to the same thing). If that is true by definition, then the claim falls into the "vacuously true" category. Can you define what is meant for a language to be interesting in such a way that undefined behavior is not inherently built into the definition? > Perhaps you could explain your reasoning more closely. I would be happy to, pending an answer to my question above.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-07 08:25 +0000 |
| Message-ID | <J9Ugw.10132$484.9349@fx46.am4> |
| In reply to | #53944 |
Tim Rentsch wrote: > Can you define what is meant for a language > to be interesting in such a way that undefined behavior is > not inherently built into the definition? No, I don't think I can, but that doesn't (necessarily, at least) mean I'm wrong - it just means I'm struggling to define a fairly nebulous concept. But a language in which every string is either illegal or well-defined would, it seems to me, tend to make it more difficult to innovate in ways unanticipated by the language designer. The obvious way around this is for the implementor to provide wrappers around new behaviours, so that the programmer can gain access to those new behaviours via a function call, but the implementor cannot use the language itself to implement the functionality behind those wrappers (if this /were/ possible, the wrapper would not be necessary in the first place), and must resort to a more powerful language instead. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2014-12-07 10:44 -0800 |
| Message-ID | <c9610702-8a60-4264-93aa-db6920387f8f@googlegroups.com> |
| In reply to | #54026 |
On Sunday, 7 December 2014 10:25:23 UTC+2, Richard Heathfield wrote: > Tim Rentsch wrote: > > > Can you define what is meant for a language > > to be interesting in such a way that undefined behavior is > > not inherently built into the definition? > > No, I don't think I can, but that doesn't (necessarily, at least) mean I'm > wrong - it just means I'm struggling to define a fairly nebulous concept. > But a language in which every string is either illegal or well-defined > would, it seems to me, tend to make it more difficult to innovate in ways > unanticipated by the language designer. Programming language is a tool of writing software like for example microscope is a tool of of seeing small objects. You may want to use microscope "inventively" for beating nails into wood. Is the microscope "uninteresting" if it starts to scream against such barbaric behavior? The automatic safeguards against some situations in program can be expensive compile-time and/or run-time so such situations are left undefined behavior in C and up to developer to avoid. How can lack of such safeguards (or at least building blocks of such safeguards) be viewed as sign of a power or weakness of tool? On the contrary, also for C we have multitude of static code analyzers, libraries and debug facilities that help with such things. It feels unfortunate that not much of it has been standardized. > The obvious way around this is for the implementor to provide wrappers > around new behaviours, so that the programmer can gain access to those > new behaviours via a function call, but the implementor cannot use the > language itself to implement the functionality behind those wrappers > (if this /were/ possible, the wrapper would not be necessary in the > first place), and must resort to a more powerful language instead. I probably need some example of such "wrappers" or something for to understand above paragraph. Do you mean that if there is a feature of new hardware that C standard does not define then we need undefined behavior to write code for using it? The features that we use are always defined, even if not by C standard. No black magic is needed.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-07 19:17 +0000 |
| Message-ID | <NI1hw.11652$8q6.426@fx25.am4> |
| In reply to | #54046 |
Öö Tiib wrote: > On Sunday, 7 December 2014 10:25:23 UTC+2, Richard Heathfield wrote: >> Tim Rentsch wrote: >> >> > Can you define what is meant for a language >> > to be interesting in such a way that undefined behavior is >> > not inherently built into the definition? >> >> No, I don't think I can, but that doesn't (necessarily, at least) mean >> I'm wrong - it just means I'm struggling to define a fairly nebulous >> concept. But a language in which every string is either illegal or >> well-defined would, it seems to me, tend to make it more difficult to >> innovate in ways unanticipated by the language designer. > > Programming language is a tool of writing software like for example > microscope is a tool of of seeing small objects. You may want to use > microscope "inventively" for beating nails into wood. Is the microscope > "uninteresting" if it starts to scream against such barbaric behavior? It's a poor analogy, because computers are used for so much more than are microscopes. It is reasonable to reject the microscope as a replacement hammer, but that doesn't mean it is unreasonable to accept that there may be many uses for a computer that we haven't currently considered. > > The automatic safeguards against some situations in program can be > expensive compile-time and/or run-time so such situations are left > undefined behavior in C and up to developer to avoid. How can lack > of such safeguards (or at least building blocks of such safeguards) > be viewed as sign of a power or weakness of tool? Firstly, this isn't what we're talking about, but secondly, you answered your own question. Safeguards can be expensive, and so there will always be those programmers who wish to dispense with them on the grounds that they are unnecessary burdens. Such programmers do of course run the risk of falling foul of the dangers that the safeguards were there to guard against but, if they are prepared to run that risk, that's up to them. But I think that's a side issue. We're talking about whether defining the effect of every syntactically correct and constraint-violation-free statement restricts (or does not restrict) a language in terms of innovation. > > On the contrary, also for C we have multitude of static code analyzers, > libraries and debug facilities that help with such things. It feels > unfortunate that not much of it has been standardized. Standardisation of such tools would indeed be a good thing, but that doesn't mean that there isn't room for tools that push the boundaries and move beyond the envelope defined by those putative standards. > >> The obvious way around this is for the implementor to provide wrappers >> around new behaviours, so that the programmer can gain access to those >> new behaviours via a function call, but the implementor cannot use the >> language itself to implement the functionality behind those wrappers >> (if this /were/ possible, the wrapper would not be necessary in the >> first place), and must resort to a more powerful language instead. > > I probably need some example of such "wrappers" or something for to > understand above paragraph. Do you mean that if there is a feature of > new hardware that C standard does not define then we need undefined > behavior to write code for using it? The features that we use are > always defined, even if not by C standard. We're talking about the language definition, i.e. the C Standard in our case. If you are arguing (and it seems that you are) that there are times when we need to step outside the C Standard in order to take advantage of hardware features that it did not anticipate and does not support, then I agree with you (or rather, you agree with me). > No black magic is needed. Magic is about knowing one extra fact. If the C Standard says that X is undefined but you know that X achieves Y, then you know one extra fact that the C Standard doesn't know, and you can use that fact to do Y magic. But if the C Standard requires that X (which, up until the invention of Y functionality, had no particular value) does Z (e.g. it requires that *(unsigned char *)addr = value; is equivalent to, say, a NOP), then you wouldn't be able to use X to do Y after all. You'd have to pick a less picky language. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2014-12-07 15:48 -0800 |
| Message-ID | <a53e0333-49b9-4b81-9368-bada53808eee@googlegroups.com> |
| In reply to | #54047 |
On Sunday, 7 December 2014 21:17:10 UTC+2, Richard Heathfield wrote: > Öö Tiib wrote: > > > On Sunday, 7 December 2014 10:25:23 UTC+2, Richard Heathfield wrote: > >> Tim Rentsch wrote: > >> > >> > Can you define what is meant for a language > >> > to be interesting in such a way that undefined behavior is > >> > not inherently built into the definition? > >> > >> No, I don't think I can, but that doesn't (necessarily, at least) mean > >> I'm wrong - it just means I'm struggling to define a fairly nebulous > >> concept. But a language in which every string is either illegal or > >> well-defined would, it seems to me, tend to make it more difficult to > >> innovate in ways unanticipated by the language designer. > > > > Programming language is a tool of writing software like for example > > microscope is a tool of of seeing small objects. You may want to use > > microscope "inventively" for beating nails into wood. Is the microscope > > "uninteresting" if it starts to scream against such barbaric behavior? > > It's a poor analogy, because computers are used for so much more than are > microscopes. It is reasonable to reject the microscope as a replacement > hammer, but that doesn't mean it is unreasonable to accept that there may be > many uses for a computer that we haven't currently considered. I still do not see a reason why we need any undefined behavior in programming language for such usages. > > The automatic safeguards against some situations in program can be > > expensive compile-time and/or run-time so such situations are left > > undefined behavior in C and up to developer to avoid. How can lack > > of such safeguards (or at least building blocks of such safeguards) > > be viewed as sign of a power or weakness of tool? > > Firstly, this isn't what we're talking about, but secondly, you answered > your own question. Safeguards can be expensive, and so there will always be > those programmers who wish to dispense with them on the grounds that they > are unnecessary burdens. Such programmers do of course run the risk of > falling foul of the dangers that the safeguards were there to guard against > but, if they are prepared to run that risk, that's up to them. So as result the compiler is for example 3 times simpler and they get a program that runs for example 1.5 times faster or uses 1.5 times less battery power. It is gain in practice indeed but we aren't discussing that. We are discussing how that can be the difference between interesting and uninteresting? > But I think that's a side issue. We're talking about whether defining > the effect of every syntactically correct and constraint-violation-free > statement restricts (or does not restrict) a language in terms of > innovation. How? Let me try another analogy. There is a universe with every rule of nature clearly set and fully determined. Like game of life just significantly more complex. What is the reason to call it uninteresting universe? > > On the contrary, also for C we have multitude of static code analyzers, > > libraries and debug facilities that help with such things. It feels > > unfortunate that not much of it has been standardized. > > Standardisation of such tools would indeed be a good thing, but that doesn't > mean that there isn't room for tools that push the boundaries and move > beyond the envelope defined by those putative standards. What boundaries? It is not trick question. I have been writing software for various problem domains for decades and there is often a need to be inventive but it has been always good idea to avoid undefined behavior. > >> The obvious way around this is for the implementor to provide wrappers > >> around new behaviours, so that the programmer can gain access to those > >> new behaviours via a function call, but the implementor cannot use the > >> language itself to implement the functionality behind those wrappers > >> (if this /were/ possible, the wrapper would not be necessary in the > >> first place), and must resort to a more powerful language instead. > > > > I probably need some example of such "wrappers" or something for to > > understand above paragraph. Do you mean that if there is a feature of > > new hardware that C standard does not define then we need undefined > > behavior to write code for using it? The features that we use are > > always defined, even if not by C standard. > > We're talking about the language definition, i.e. the C Standard in our > case. If you are arguing (and it seems that you are) that there are times > when we need to step outside the C Standard in order to take advantage of > hardware features that it did not anticipate and does not support, then I > agree with you (or rather, you agree with me). No. I meant that there are times when we need some other standards. For example ISO-9660 for making a file system that is compliant with that standard. We may make new standards or we may extend existing standards. It does not mean we need to write these details to C standard or to write C code that contains undefined behavior for creating new file system. > > No black magic is needed. > > Magic is about knowing one extra fact. If the C Standard says that X is > undefined but you know that X achieves Y, then you know one extra fact that > the C Standard doesn't know, and you can use that fact to do Y magic. But if > the C Standard requires that X (which, up until the invention of Y > functionality, had no particular value) does Z (e.g. it requires that > *(unsigned char *)addr = value; is equivalent to, say, a NOP), then you > wouldn't be able to use X to do Y after all. You'd have to pick a less picky > language. You mean that the type punning is somehow important and interesting feature? Like that 0x5f3759df trick "Fast inverse square root" invented by Silicon Graphics? The gain was maybe 4 times faster floating point operation. If it is so important formula then it can be implemented in hardware. I do not see where and how you exactly *need* undefined behavior for to achieve something actually new.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2014-12-08 05:45 +0000 |
| Message-ID | <0Wahw.46732$Z36.1849@fx36.am4> |
| In reply to | #54052 |
Öö Tiib wrote: > On Sunday, 7 December 2014 21:17:10 UTC+2, Richard Heathfield wrote: <snip> >> But I think that's a side issue. We're talking about whether defining >> the effect of every syntactically correct and constraint-violation-free >> statement restricts (or does not restrict) a language in terms of >> innovation. > > How? Let me try another analogy. There is a universe with every rule of > nature clearly set and fully determined. Like game of life just > significantly more complex. What is the reason to call it uninteresting > universe? I think it would be a very interesting universe indeed, but I wouldn't call it a programming language. > >> > On the contrary, also for C we have multitude of static code analyzers, >> > libraries and debug facilities that help with such things. It feels >> > unfortunate that not much of it has been standardized. >> >> Standardisation of such tools would indeed be a good thing, but that >> doesn't mean that there isn't room for tools that push the boundaries and >> move beyond the envelope defined by those putative standards. > > What boundaries? It is not trick question. I have been writing software > for various problem domains for decades and there is often a need to be > inventive but it has been always good idea to avoid undefined behavior. Yes, it's always a good idea to avoid undefined behaviour, simply because undefined behaviour is non-portable - even if you can rely on it on one particular machine type, that doesn't mean you can rely on it on other machine types. But there are times when you simply have to have the behaviour that your own target machine offers, and the only way to get it is to step out of the language. Let me give you an example: you have, have, HAVE to know how many clock cycles have occurred since the last boot. C offers no well-defined way to do this. <snip> >> We're talking about the language definition, i.e. the C Standard in our >> case. If you are arguing (and it seems that you are) that there are times >> when we need to step outside the C Standard in order to take advantage of >> hardware features that it did not anticipate and does not support, then I >> agree with you (or rather, you agree with me). > > No. I meant that there are times when we need some other standards. For > example ISO-9660 for making a file system that is compliant with that > standard. We may make new standards or we may extend existing standards. > It does not mean we need to write these details to C standard or to write > C code that contains undefined behavior for creating new file system. If you don't write the details in the C Standard, then the C Standard doesn't define them, in which case they're not defined by the C Standard, in which case they are undefined by C, which is what we're talking about. > >> > No black magic is needed. >> >> Magic is about knowing one extra fact. If the C Standard says that X is >> undefined but you know that X achieves Y, then you know one extra fact >> that the C Standard doesn't know, and you can use that fact to do Y >> magic. But if the C Standard requires that X (which, up until the >> invention of Y functionality, had no particular value) does Z (e.g. it >> requires that *(unsigned char *)addr = value; is equivalent to, say, a >> NOP), then you wouldn't be able to use X to do Y after all. You'd have to >> pick a less picky language. > > You mean that the type punning is somehow important and interesting > feature? No, I mean that forbidding it is a retrograde step. > Like that 0x5f3759df trick "Fast inverse square root" invented by > Silicon Graphics? The gain was maybe 4 times faster floating point > operation. If it is so important formula then it can be implemented in > hardware. And then you will change the C Standard so that it defines an interface to that hardware, will you? And then what will you do with all the platforms that don't have that hardware? > I do not see where and how you exactly *need* undefined behavior > for to achieve something actually new. This may be because you have a different understanding of the concept of "undefined behaviour" than I do. I am talking specifically about what the language definition (the C Standard) refuses to define for itself and does not require the implementation to define either. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web