Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #39232 > unrolled thread
| Started by | chitselb <chitselb@gmail.com> |
|---|---|
| First post | 2015-05-23 19:27 -0700 |
| Last post | 2015-05-24 14:06 +0000 |
| Articles | 20 on this page of 151 — 19 participants |
Back to article view | Back to comp.lang.forth
unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 19:27 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 20:27 -0700
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 13:44 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:36 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-24 23:16 +0200
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 15:57 -0700
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-25 02:21 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-24 15:21 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 19:49 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:22 -0700
Re: unexpected +LOOP behavior "WJ" <w_a_x_man@yahoo.com> - 2015-05-26 17:20 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 14:15 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 08:37 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 15:09 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 09:19 -1000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 17:08 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 15:42 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 19:30 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 17:45 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-26 21:33 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 14:08 +0200
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 06:32 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 16:15 +0200
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-26 14:32 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 08:30 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:15 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-29 21:05 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 01:41 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-24 23:26 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:33 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 10:56 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-25 11:28 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 14:33 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:57 -0700
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 23:01 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 14:21 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-26 23:59 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 09:15 +0000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 10:06 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:03 -0400
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-27 16:23 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 12:39 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 22:14 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 17:13 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-27 23:36 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 18:06 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:35 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:16 +0100
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 09:42 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 16:16 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 15:24 +0100
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:32 -0400
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-27 23:59 +0200
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-27 19:31 -0400
Re: unexpected +LOOP behavior Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-05-27 23:11 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:21 +0100
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-28 12:24 +0100
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 10:53 +0200
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:19 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:51 +0000
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-29 17:48 +0200
Re: unexpected +LOOP behavior Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-29 02:08 +0200
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 08:25 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:40 +0100
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:16 +0000
Re: unexpected +LOOP behavior albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-29 18:43 +0000
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 20:08 +0100
x86 tricks Lars Brinkhoff <lars.spam@nocrew.org> - 2015-06-05 09:42 +0200
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 09:32 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 09:40 +0000
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-05 11:17 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 15:49 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 17:45 +0100
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-05 16:53 +0000
Re: x86 tricks rickman <gnuarm@gmail.com> - 2015-06-07 13:20 -0400
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 07:18 +0000
Re: x86 tricks Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-08 17:18 +0200
Re: x86 tricks Tessa Bonting <tessa.bonting@gmail.com> - 2015-06-08 08:42 -0700
Re: x86 tricks albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-06-06 09:47 +0000
Re: x86 tricks anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 15:05 +0000
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-07 17:49 +0100
Re: x86 tricks "Alex McDonald" <blog@rivadpm.com> - 2015-06-05 13:19 +0100
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:38 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 21:33 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-23 22:10 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-23 22:20 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 21:13 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:34 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 22:04 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 01:27 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-28 03:20 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-28 04:13 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 04:23 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 11:28 -0400
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-29 18:32 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-29 18:53 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-23 22:26 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-23 21:37 -1000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:24 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:40 -0400
Re: unexpected +LOOP behavior Hans Bezemer <the.beez.speaks@gmail.com> - 2015-05-25 14:08 +0200
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:47 -1000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-27 17:33 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 12:53 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 13:05 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 14:49 -1000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 18:03 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-05-25 16:44 -1000
Re: unexpected +LOOP behavior humptydumpty <ouatubi@gmail.com> - 2015-05-25 22:56 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:05 +0000
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:43 -0400
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-24 08:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 15:44 +0000
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-27 00:57 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-06-05 13:11 -0700
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-05 12:24 -1000
Re: unexpected +LOOP behavior JennyB <jennybrien@googlemail.com> - 2015-06-06 13:29 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-07 14:56 +0000
Re: unexpected +LOOP behavior "Elizabeth D. Rather" <erather@forth.com> - 2015-06-07 10:38 -1000
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-08 08:08 +0000
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 10:01 -0700
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-24 10:40 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 11:29 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 09:51 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 10:44 -0700
Re: unexpected +LOOP behavior "Alex McDonald" <blog@rivadpm.com> - 2015-05-25 12:34 -0700
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-25 12:59 -0700
unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-24 01:39 -0700
Re: unexpected +LOOP behavior Coos Haak <chforth@hccnet.nl> - 2015-05-24 14:46 +0200
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-25 01:17 -0700
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-24 20:48 -0400
Re: unexpected +LOOP behavior hughaguilar96@gmail.com - 2015-05-24 18:15 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-25 12:35 +0000
Re: unexpected +LOOP behavior "Rod Pemberton" <fork@lllljunkqwer.cpm> - 2015-05-25 17:27 -0400
Re: unexpected +LOOP behavior rickman <gnuarm@gmail.com> - 2015-05-25 18:16 -0400
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 16:17 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 17:16 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 17:50 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 18:47 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-25 20:01 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:29 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-25 20:32 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-26 08:03 +0000
Re: unexpected +LOOP behavior Mark Wills <markwills1970@gmail.com> - 2015-05-26 01:10 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:31 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 20:07 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-26 20:20 -0700
Re: unexpected +LOOP behavior Michael Barry <barrym95838@yahoo.com> - 2015-05-26 22:00 -0700
Re: unexpected +LOOP behavior chitselb <chitselb@gmail.com> - 2015-05-27 02:41 -0700
Re: unexpected +LOOP behavior anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-24 14:06 +0000
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | chitselb <chitselb@gmail.com> |
|---|---|
| Date | 2015-05-23 19:27 -0700 |
| Subject | unexpected +LOOP behavior |
| Message-ID | <80773739-ddd7-4a06-9200-9d7145d0f492@googlegroups.com> |
I'm reimplementing +LOOP in my homebrew Forth, and want to mostly do the right thing with standard words. This is what gforth does: : foo 0 20 do i . -3 +loop ; foo 20 17 14 11 8 5 2 ok : foo 20 0 do i . 3 +loop ; foo 0 3 6 9 12 15 18 ok ( 7 iterations ) : foo 0 20 do i . -2 +loop ; foo 20 18 16 14 12 10 8 6 4 2 0 ok : foo 20 0 do i . 2 +loop ; foo 0 2 4 6 8 10 12 14 16 18 ok : foo 0 20 do i . -1 +loop ; foo 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ok : foo 20 0 do i . 1 +loop ; foo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ok : foo 20 0 do i . loop ; foo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ok : foo 0 20 do i . -4 +loop ; foo 20 16 12 8 4 0 ok : foo 20 0 do i . 4 +loop ; foo 0 4 8 12 16 ok These results threw me off. Why does the standard have that extra iteration for negative loop increments?
[toc] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-23 20:27 -0700 |
| Message-ID | <763a0671-2f81-4a26-aa7b-99aa856cfdcb@googlegroups.com> |
| In reply to | #39232 |
On Saturday, May 23, 2015 at 7:27:29 PM UTC-7, chitselb wrote: > I'm reimplementing +LOOP in my homebrew Forth, and want to mostly do the right thing with standard words. This is what gforth does: > > : foo 0 20 do i . -3 +loop ; > foo 20 17 14 11 8 5 2 ok > : foo 20 0 do i . 3 +loop ; > foo 0 3 6 9 12 15 18 ok > ( 7 iterations ) > > > : foo 0 20 do i . -2 +loop ; > foo 20 18 16 14 12 10 8 6 4 2 0 ok > : foo 20 0 do i . 2 +loop ; > foo 0 2 4 6 8 10 12 14 16 18 ok > > : foo 0 20 do i . -1 +loop ; > foo 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ok > : foo 20 0 do i . 1 +loop ; > foo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ok > : foo 20 0 do i . loop ; > foo 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 ok > > : foo 0 20 do i . -4 +loop ; > foo 20 16 12 8 4 0 ok > : foo 20 0 do i . 4 +loop ; > foo 0 4 8 12 16 ok > > These results threw me off. Why does the standard have that extra iteration for negative loop increments? Everybody finds this to be non-intuitive. This is one of several reasons why I won't have DO loops in my Forth. DO loops are 1970s vintage cruft --- they have no place in a modern Forth system. See 6.1.0140 in the ANS-Forth document for a description of +LOOP --- it says: "If the loop index did not cross the boundary between the loop limit minus one and the loop limit, continue execution at the beginning of the loop." Intuitively, you would expect it to be 1 minus the limit when going up and 1 plus the limit when going down. Whether you are going up or down though, the boundary is always 1 minus the limit. This allows for a clever trick in implementing +LOOP so the same code will work whether going up or down. Also, LOOP will work with both signed and unsigned numbers. None of this cleverness was possible on the MiniForth processor because it didn't have an overflow flag. This is one of many examples of how ANS-Forth standardized implementation rather than behavior. DO loops are very clever from an implementation standpoint --- quite baffling for the user though --- I largely ignore them.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-24 13:44 +0200 |
| Message-ID | <5561b9b6$0$2868$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39233 |
hughaguilar96@gmail.com wrote: > Everybody finds this to be non-intuitive. This is one of several reasons > why I won't have DO loops in my Forth. DO loops are 1970s vintage cruft > --- they have no place in a modern Forth system. > > See 6.1.0140 in the ANS-Forth document for a description of +LOOP --- it > says: "If the loop index did not cross the boundary between the loop limit > minus one and the loop limit, continue execution at the beginning of the > loop." > > Intuitively, you would expect it to be 1 minus the limit when going up and > 1 plus the limit when going down. Whether you are going up or down though, > the boundary is always 1 minus the limit. > > This allows for a clever trick in implementing +LOOP so the same code will > work whether going up or down. Also, LOOP will work with both signed and > unsigned numbers. AFAIK this behavior was introduced by Forth-83. Fig and Forth-79 behaved much more sane - so I kept this behavior in my own 4tH. Yes, these Forth-83 guys thought they were pretty clever. The unsigned option allowed them to use the thing in their "2 byte" cells standard to cover the entire address range. "Counter intuitive?" they boasted "Oh no, n00bs just need to read the documentation properly". It was Forth-83 that pulled me away from Forth - I thought it was that ghastly. So, when I started 4tH, it was Forth-79. To make a long story short, I added much Forth-94 compatibility, but never up to the point that I added +LOOP compatibility. Forth-83 added lots of horrible, "clever" tricks that made the language almost unusable. "All bits set" for TRUE was another one. Really, it's no wonder Forth went through the drain in the late 80-ies. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-24 10:36 -0400 |
| Message-ID | <mjsnid$99v$2@dont-email.me> |
| In reply to | #39244 |
On 5/24/2015 7:44 AM, Hans Bezemer wrote: > > Forth-83 added lots of horrible, "clever" tricks that made the language > almost unusable. "All bits set" for TRUE was another one. Really, it's no > wonder Forth went through the drain in the late 80-ies. What is wrong with using -1 for a logic TRUE? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-24 23:16 +0200 |
| Message-ID | <55623fa0$0$2821$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39247 |
rickman wrote: > On 5/24/2015 7:44 AM, Hans Bezemer wrote: >> >> Forth-83 added lots of horrible, "clever" tricks that made the language >> almost unusable. "All bits set" for TRUE was another one. Really, it's no >> wonder Forth went through the drain in the late 80-ies. > > What is wrong with using -1 for a logic TRUE? Ok, here we go again: Another nice topic for a flame war is the value of truth. In ANS-Forth the 'TRUE' has the value "-1", which means all bits are set. Which is very clever. You can 'XOR', 'OR', 'AND' and 'INVERT' it with any other value and it will behave as logical value. But "the all bits set" flag has its drawbacks too. Let's see what the ANS-Forth standard says about flags: "A FALSE flag is a single-cell datum with all bits unset, and a TRUE flag is a single-cell datum with all bits set. While Forth words which test flags accept any non-null bit pattern as true, there exists the concept of the well-formed flag. If an operation whose result is to be used as a flag may produce any bit-mask other than TRUE or FALSE, the recommended discipline is to convert the result to a well-formed flag by means of the Forth word 0<> so that the result of any subsequent logical operations on the flag will be predictable. In addition to the words which move, fetch and store single-cell items, the following words are valid for operations on one or more flag data residing on the data stack: AND OR XOR INVERT" We highly recommend the discipline of converting a non-zero value to a well-formed flag. But we don't understand why 'INVERT' is a valid way to manipulate a flag. We'll try to explain you why. Forth traditionally has no specific logical operators. Instead, binary operators were used. This put 'INVERT' (or 'NOT' as it was called in Forth-79) in a difficult position. 'INVERT'ing any non-zero value will result in a non-zero value, except when all bits are set. That is why '0=' was introduced, a full-fledged logical operator. So why use 'INVERT' when you want to perform a logical operation? Another quote: "Since a "char" can store small positive numbers and since the character data type is a sub-range of the unsigned integer data type, C! must store the n least-significant bits of a cell (8 <= n <= bits/cell). Given the enumeration of allowed number representations and their known encodings, "TRUE xx C! xx C@" must leave a stack item with some number of bits set, which will thus will be accepted as non-zero by IF." This is another problem of using "all bits set" as a true flag: you store a well formed flag in an address unit that should easily be able to handle it and you'll never get it back. A flag is a boolean and can have two values: either true or false. The smallest unit that can hold a boolean is a bit. ANS-Forth programmers are denied that privilege. But why are some Forth programmers so keen on their “all bits set” flag? Well, you can do neat things with it. : >CHAR DUP 9 > 7 AND + ASCII 0 + ; This will convert a digit to its ASCII representation. True, it is a clever piece of programming, but in our opinion it is bad style. Why? Because you are using a flag as a bitmask, which is a completely different datatype. Although there is no such thing as “data typing” in Forth, this way of programming makes it difficult to understand and maintain a program, which the ANS-Forth standard acknowledges: "The discipline of circumscribing meaning which a program may assign to various combinations of bit patterns is sometimes called data typing. Many computer languages impose explicit data typing and have compilers that prevent ill-defined operations. Forth rarely explicitly imposes data-type restrictions. Still, data types implicitly do exist, and discipline is required, particularly if portability of programs is a goal. In Forth, it is incumbent upon the programmer (rather than the compiler) to determine that data are accurately typed." That is why 4tH uses "1" as a true flag. Usually, it won't make much difference. Except when you use 'INVERT' to invert a flag or intend to make obfuscated programs. If you use '0=' instead, you won't run in any trouble, not even when you port your program to ANS-Forth. Clarity may introduce a little overhead, but in this age of multi-gigaherz machines, who is counting? Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-24 15:57 -0700 |
| Message-ID | <32992aa6-bd26-43f0-902c-684b2877baa0@googlegroups.com> |
| In reply to | #39257 |
On Sunday, May 24, 2015 at 2:16:43 PM UTC-7, The Beez wrote: > That is why 4tH uses "1" as a true flag. Usually, it won't make > much difference. Except when you use 'INVERT' to invert a flag or > intend to make obfuscated programs. If you use '0=' instead, you > won't run in any trouble, not even when you port your program to > ANS-Forth. Clarity may introduce a little overhead, but in this > age of multi-gigaherz machines, who is counting? I will have TRUE being 1 in my Forth too. It is useful because the flag can be added to a count. This is efficient and readable. Also, counting is a pretty common task for computers, so this use-case is going to come up often. Using a flag as a mask for logical operations might be efficient, but it is not very readable. If a programmer really wants to do this, then he can NEGATE his flag to change it from 0|1 to 0|-1 --- the code is already going to be pretty much unreadable, so having a NEGATE in the middle of it won't make it much worse. This use-case won't come up often --- I've only done it a very few times in my many years of Forth programming, and I thought the result was ugly every time.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-25 02:21 +0200 |
| Message-ID | <mjtpra$6ji$1@dont-email.me> |
| In reply to | #39257 |
Hans Bezemer wrote: > But why are some Forth programmers so keen on their “all bits set” > flag? Well, you can do neat things with it. > > : >CHAR DUP 9 > 7 AND + ASCII 0 + ; > > This will convert a digit to its ASCII representation. True, it > is a clever piece of programming, but in our opinion it is bad > style. Why? Because you are using a flag as a bitmask, which is a > completely different datatype. Although there is no such thing as > “data typing” in Forth, this way of programming makes it > difficult to understand and maintain a program, which the > ANS-Forth standard acknowledges: Honestly, this is only a problem if you don't know that idiom. A lot of people don't know that you can use masks and logical operations, so they will find that operation strange. I recall Andy Glew (who's one of the architects of the P6/Pentium II microarchitecture) telling a story that he proposed all-bit-set flags for MMX. That's a SIMD instruction set, and creating several masks makes a lot of sense in that context. His proposal was shelfed, because his boss did not understand the idiom of bit mask operations. Andy was quite disappoined by that. Later, in SSE, the proposal was revived, and we now have such bit mask flags in SSE. Therefore, I would reiterate what I told Hugh some times: If you don't know something, it's *not* the fault of the person who uses and knows that thing. It's entirely your fault, and if you want to be a wise person, you'd rather learn it that complain. IMHO the whole datatype based thinking about cells in Forth is ill-advised. First, and foremost, a cell is a bit pattern, and if you add and subtract it, it's a mod 2^n ring. You can use that to some degrees as integer, but it's not an integer. It's a cell. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-24 15:21 -1000 |
| Message-ID | <6didnZCtx-m85P_InZ2dnUU7-I2dnZ2d@supernews.com> |
| In reply to | #39262 |
On 5/24/15 2:21 PM, Bernd Paysan wrote: > Hans Bezemer wrote: > >> But why are some Forth programmers so keen on their “all bits set” >> flag? Well, you can do neat things with it. >> >> : >CHAR DUP 9 > 7 AND + ASCII 0 + ; >> >> This will convert a digit to its ASCII representation. True, it >> is a clever piece of programming, but in our opinion it is bad >> style. Why? Because you are using a flag as a bitmask, which is a >> completely different datatype. Although there is no such thing as >> “data typing” in Forth, this way of programming makes it >> difficult to understand and maintain a program, which the >> ANS-Forth standard acknowledges: > > Honestly, this is only a problem if you don't know that idiom. A lot of > people don't know that you can use masks and logical operations, so they > will find that operation strange. > > I recall Andy Glew (who's one of the architects of the P6/Pentium II > microarchitecture) telling a story that he proposed all-bit-set flags for > MMX. That's a SIMD instruction set, and creating several masks makes a lot > of sense in that context. His proposal was shelfed, because his boss did > not understand the idiom of bit mask operations. Andy was quite disappoined > by that. > > Later, in SSE, the proposal was revived, and we now have such bit mask flags > in SSE. > > Therefore, I would reiterate what I told Hugh some times: If you don't know > something, it's *not* the fault of the person who uses and knows that thing. > It's entirely your fault, and if you want to be a wise person, you'd rather > learn it that complain. > > IMHO the whole datatype based thinking about cells in Forth is ill-advised. > First, and foremost, a cell is a bit pattern, and if you add and subtract > it, it's a mod 2^n ring. You can use that to some degrees as integer, but > it's not an integer. It's a cell. > Thank, you, Bernd, well-said. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-24 19:49 -0700 |
| Message-ID | <9fdc3d9a-ad87-4623-bdc7-99afedbc23ee@googlegroups.com> |
| In reply to | #39268 |
On Sunday, May 24, 2015 at 6:21:38 PM UTC-7, Elizabeth D. Rather wrote:
> On 5/24/15 2:21 PM, Bernd Paysan wrote:
> > Hans Bezemer wrote:
> >
> >> But why are some Forth programmers so keen on their "all bits set"
> >> flag? Well, you can do neat things with it.
> >>
> >> : >CHAR DUP 9 > 7 AND + ASCII 0 + ;
> >>
> >> This will convert a digit to its ASCII representation. True, it
> >> is a clever piece of programming, but in our opinion it is bad
> >> style. Why? Because you are using a flag as a bitmask, which is a
> >> completely different datatype. Although there is no such thing as
> >> "data typing" in Forth, this way of programming makes it
> >> difficult to understand and maintain a program, which the
> >> ANS-Forth standard acknowledges:
> >
> > Honestly, this is only a problem if you don't know that idiom. A lot of
> > people don't know that you can use masks and logical operations, so they
> > will find that operation strange.
It is not that I don't know that you can use masks and logical operations --- it is just that the code is ugly as sin.
For one thing, 7 is a magic number that nobody is going to fathom unless they have the ascii character set memorized. Even if you make 7 a constant (I don't know what you would name it), the code is still just convoluted-ugly.
For another thing, the code is not general-purpose, as all it does is convert numbers into hexadecimal digits.
This is really not the quality of code that I put in the novice package.
This is what will go in the novice package:
: indexed-char ( index str -- char )
count \ -- index adr cnt
rover 0< abort" *** INDEXED-CHAR given a negative index ***"
rover <= abort" *** INDEXED-CHAR given an index too large ***"
+ c@ ;
: hexit>char ( [0,15] -- char )
c" 0123456789ABCDEF" indexed-char ;
This is the novice-package idiom --- INDEXED-CHAR is general-purpose code and HEXIT>CHAR is highly readable.
> > Therefore, I would reiterate what I told Hugh some times: If you don't know
> > something, it's *not* the fault of the person who uses and knows that thing.
> > It's entirely your fault, and if you want to be a wise person, you'd rather
> > learn it that complain.
> >
> > IMHO the whole datatype based thinking about cells in Forth is ill-advised.
> > First, and foremost, a cell is a bit pattern, and if you add and subtract
> > it, it's a mod 2^n ring. You can use that to some degrees as integer, but
> > it's not an integer. It's a cell.
>
> Thank, you, Bernd, well-said.
Or, as the Skipper said to Gilligan: "Put it there, little buddy!" (that second paragraph sounds more like something that the Professor would say, rather than Gilligan).
Neither Bernd Payson nor Elizabeth Rather know how to write general-purpose code, nor do they know how to write readable code --- idiots babbling about idioms! --- they are just addicted to the idea that they are "leading experts" and that they set the standard for the plebeians such as myself, but they know nothing about Forth programming.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-24 18:22 -0700 |
| Message-ID | <016f8e64-d57b-4d8d-b43f-c2ccc1815023@googlegroups.com> |
| In reply to | #39262 |
On Sunday, May 24, 2015 at 5:21:05 PM UTC-7, Bernd Paysan wrote: > Therefore, I would reiterate what I told Hugh some times: If you don't know > something, it's *not* the fault of the person who uses and knows that thing. > It's entirely your fault, and if you want to be a wise person, you'd rather > learn it that complain. LOL You are still mad because I know what quotations are --- your effort at faking up :NONAME as a quotation didn't get past me. You are a phony Bernd --- you totally faked that code --- you should have just admitted that you didn't know how to implement quotations and done nothing, rather than fake it and put a black mark on the entire Forth community.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-05-26 17:20 +0000 |
| Message-ID | <mk2a0b$ohr$1@dont-email.me> |
| In reply to | #39262 |
Bernd Paysan wrote: > > But why are some Forth programmers so keen on their “all bits set” > > flag? Well, you can do neat things with it. > > > > : >CHAR DUP 9 > 7 AND + ASCII 0 + ; > > > > This will convert a digit to its ASCII representation. True, it > > is a clever piece of programming, but in our opinion it is bad > > style. Why? Because you are using a flag as a bitmask, which is a > > completely different datatype. Although there is no such thing as > > “data typing” in Forth, this way of programming makes it > > difficult to understand and maintain a program, which the > > ANS-Forth standard acknowledges: > > Honestly, this is only a problem if you don't know that idiom. That code is unreadable and unmaintainable. It's very hard to figure out how it accomplishes its task. I would not pay a programmer to produce code like that. This is somewhat more understandable: : >char dup 9 > if [char] A 10 - else [char] 0 then + ;
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-26 14:15 -0400 |
| Message-ID | <mk2d57$6qg$1@dont-email.me> |
| In reply to | #39331 |
On 5/26/2015 1:20 PM, WJ wrote: > Bernd Paysan wrote: > >>> But why are some Forth programmers so keen on their “all bits set” >>> flag? Well, you can do neat things with it. >>> >>> : >CHAR DUP 9 > 7 AND + ASCII 0 + ; >>> >>> This will convert a digit to its ASCII representation. True, it >>> is a clever piece of programming, but in our opinion it is bad >>> style. Why? Because you are using a flag as a bitmask, which is a >>> completely different datatype. Although there is no such thing as >>> “data typing” in Forth, this way of programming makes it >>> difficult to understand and maintain a program, which the >>> ANS-Forth standard acknowledges: >> >> Honestly, this is only a problem if you don't know that idiom. > > That code is unreadable and unmaintainable. It's very hard > to figure out how it accomplishes its task. I would not > pay a programmer to produce code like that. > > This is somewhat more understandable: > > : >char > dup 9 > if [char] A 10 - else [char] 0 then > + ; If you have any reason to look at the definition of >char then I can't see how you would not understand how it works. Perhaps this would be a better definition... \ Convert n to ASCII char : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ; Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I think that exact code has been read and understood as well as maintained for many years now. I am pretty sure I have seen something similar to it way back when I was learning assembly language. I think it took me two minutes to see what it was doing. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-26 08:37 -1000 |
| Message-ID | <4_WdnWzkV5ryIPnInZ2dnUU7-VWdnZ2d@supernews.com> |
| In reply to | #39332 |
On 5/26/15 8:15 AM, rickman wrote: > On 5/26/2015 1:20 PM, WJ wrote: >> Bernd Paysan wrote: >> >>>> But why are some Forth programmers so keen on their “all bits set” >>>> flag? Well, you can do neat things with it. >>>> >>>> : >CHAR DUP 9 > 7 AND + ASCII 0 + ; >>>> >>>> This will convert a digit to its ASCII representation. True, it >>>> is a clever piece of programming, but in our opinion it is bad >>>> style. Why? Because you are using a flag as a bitmask, which is a >>>> completely different datatype. Although there is no such thing as >>>> “data typing” in Forth, this way of programming makes it >>>> difficult to understand and maintain a program, which the >>>> ANS-Forth standard acknowledges: >>> >>> Honestly, this is only a problem if you don't know that idiom. >> >> That code is unreadable and unmaintainable. It's very hard >> to figure out how it accomplishes its task. I would not >> pay a programmer to produce code like that. >> >> This is somewhat more understandable: >> >> : >char >> dup 9 > if [char] A 10 - else [char] 0 then >> + ; > > If you have any reason to look at the definition of >char then I can't > see how you would not understand how it works. Perhaps this would be a > better definition... > > \ Convert n to ASCII char > : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ; > > Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I > think that exact code has been read and understood as well as maintained > for many years now. I am pretty sure I have seen something similar to > it way back when I was learning assembly language. I think it took me > two minutes to see what it was doing. Indeed, proper documentation as in rickman's version above is essential to readable & maintainable code. Neither of the previous versions is acceptable, although I find the shorter code quite clear (and, as rickman notes, it's been around for many years). I would have preferred [CHAR] instead of ASCII, however, as it's Standard. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-26 15:09 -0400 |
| Message-ID | <mk2gad$iat$1@dont-email.me> |
| In reply to | #39333 |
On 5/26/2015 2:37 PM, Elizabeth D. Rather wrote: > On 5/26/15 8:15 AM, rickman wrote: >> On 5/26/2015 1:20 PM, WJ wrote: >>> Bernd Paysan wrote: >>> >>>>> But why are some Forth programmers so keen on their “all bits set” >>>>> flag? Well, you can do neat things with it. >>>>> >>>>> : >CHAR DUP 9 > 7 AND + ASCII 0 + ; >>>>> >>>>> This will convert a digit to its ASCII representation. True, it >>>>> is a clever piece of programming, but in our opinion it is bad >>>>> style. Why? Because you are using a flag as a bitmask, which is a >>>>> completely different datatype. Although there is no such thing as >>>>> “data typing” in Forth, this way of programming makes it >>>>> difficult to understand and maintain a program, which the >>>>> ANS-Forth standard acknowledges: >>>> >>>> Honestly, this is only a problem if you don't know that idiom. >>> >>> That code is unreadable and unmaintainable. It's very hard >>> to figure out how it accomplishes its task. I would not >>> pay a programmer to produce code like that. >>> >>> This is somewhat more understandable: >>> >>> : >char >>> dup 9 > if [char] A 10 - else [char] 0 then >>> + ; >> >> If you have any reason to look at the definition of >char then I can't >> see how you would not understand how it works. Perhaps this would be a >> better definition... >> >> \ Convert n to ASCII char >> : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ; >> >> Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I >> think that exact code has been read and understood as well as maintained >> for many years now. I am pretty sure I have seen something similar to >> it way back when I was learning assembly language. I think it took me >> two minutes to see what it was doing. > > Indeed, proper documentation as in rickman's version above is essential > to readable & maintainable code. Neither of the previous versions is > acceptable, although I find the shorter code quite clear (and, as > rickman notes, it's been around for many years). I would have preferred > [CHAR] instead of ASCII, however, as it's Standard. I had to "see" ASCII to find exactly what it did. It seems to be state agnostic version of CHAR, [CHAR]. I wonder what that isn't used instead of the CHAR pair? Sure seems simpler to use or am I opening a can of worms by asking? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-05-26 09:19 -1000 |
| Message-ID | <zNCdneUEJZXWWvnInZ2dnUU7-LWdnZ2d@supernews.com> |
| In reply to | #39334 |
On 5/26/15 9:09 AM, rickman wrote: > On 5/26/2015 2:37 PM, Elizabeth D. Rather wrote: >> On 5/26/15 8:15 AM, rickman wrote: ... >>> \ Convert n to ASCII char >>> : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ; >>> >>> Lol, saying it is unreadable and unmaintainable is a bit of a stretch. I >>> think that exact code has been read and understood as well as maintained >>> for many years now. I am pretty sure I have seen something similar to >>> it way back when I was learning assembly language. I think it took me >>> two minutes to see what it was doing. >> >> Indeed, proper documentation as in rickman's version above is essential >> to readable & maintainable code. Neither of the previous versions is >> acceptable, although I find the shorter code quite clear (and, as >> rickman notes, it's been around for many years). I would have preferred >> [CHAR] instead of ASCII, however, as it's Standard. > > I had to "see" ASCII to find exactly what it did. It seems to be state > agnostic version of CHAR, [CHAR]. I wonder what that isn't used instead > of the CHAR pair? Sure seems simpler to use or am I opening a can of > worms by asking? CHAR/[CHAR] were adopted by the Forth94 team as part of a general movement away from state-smart words. Previously, there was mixed usage: some systems preferred ASCII and others used CHAR/[CHAR]. ASCII can't really be said to be "STATE agnostic" since it does two completely different things depending on STATE (either compiles something or pushes something on the stack). Left paren ( can truly be described as "STATE agnostic" since it does exactly the same regardless. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-26 17:08 -0400 |
| Message-ID | <mk2na2$gf3$1@dont-email.me> |
| In reply to | #39335 |
On 5/26/2015 3:19 PM, Elizabeth D. Rather wrote: > On 5/26/15 9:09 AM, rickman wrote: >> On 5/26/2015 2:37 PM, Elizabeth D. Rather wrote: >>> On 5/26/15 8:15 AM, rickman wrote: > .... >>>> \ Convert n to ASCII char >>>> : >CHAR ( n -- char ) DUP 9 > 7 AND + ASCII 0 + ; >>>> >>>> Lol, saying it is unreadable and unmaintainable is a bit of a >>>> stretch. I >>>> think that exact code has been read and understood as well as >>>> maintained >>>> for many years now. I am pretty sure I have seen something similar to >>>> it way back when I was learning assembly language. I think it took me >>>> two minutes to see what it was doing. >>> >>> Indeed, proper documentation as in rickman's version above is essential >>> to readable & maintainable code. Neither of the previous versions is >>> acceptable, although I find the shorter code quite clear (and, as >>> rickman notes, it's been around for many years). I would have preferred >>> [CHAR] instead of ASCII, however, as it's Standard. >> >> I had to "see" ASCII to find exactly what it did. It seems to be state >> agnostic version of CHAR, [CHAR]. I wonder what that isn't used instead >> of the CHAR pair? Sure seems simpler to use or am I opening a can of >> worms by asking? > > CHAR/[CHAR] were adopted by the Forth94 team as part of a general > movement away from state-smart words. Previously, there was mixed usage: > some systems preferred ASCII and others used CHAR/[CHAR]. > > ASCII can't really be said to be "STATE agnostic" since it does two > completely different things depending on STATE (either compiles > something or pushes something on the stack). Left paren ( can truly be > described as "STATE agnostic" since it does exactly the same regardless. I wasn't sure what to call it. I have seen the term "state-smart" but couldn't remember if it meant the word took care of the state or if the programmer had to deal with the state and be state "smart". Just to refresh more of my memory, why was state-smartness eschewed? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | chitselb <chitselb@gmail.com> |
|---|---|
| Date | 2015-05-26 15:42 -0700 |
| Message-ID | <1ee92851-338a-4ddd-90b0-e5113953592d@googlegroups.com> |
| In reply to | #39338 |
If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-26 19:30 -0400 |
| Message-ID | <mk2vkk$ine$1@dont-email.me> |
| In reply to | #39339 |
On 5/26/2015 6:42 PM, chitselb wrote: > If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable. Reusable? Can you explain that? -- Rick
[toc] | [prev] | [next] | [standalone]
| From | chitselb <chitselb@gmail.com> |
|---|---|
| Date | 2015-05-26 17:45 -0700 |
| Message-ID | <bfec44cc-0c17-473d-a101-02c522ad7682@googlegroups.com> |
| In reply to | #39341 |
On Tuesday, May 26, 2015 at 7:30:36 PM UTC-4, rickman wrote:
> On 5/26/2015 6:42 PM, chitselb wrote:
> > If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable.
>
> Reusable? Can you explain that?
>
> --
>
> Rick
Not good for reuse... hmm... Well, when is the last time you invoked something like this in a definition?
[COMPILE] {some-immediate-word}
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-26 21:33 -0400 |
| Message-ID | <mk36rf$5vr$2@dont-email.me> |
| In reply to | #39344 |
On 5/26/2015 8:45 PM, chitselb wrote:
> On Tuesday, May 26, 2015 at 7:30:36 PM UTC-4, rickman wrote:
>> On 5/26/2015 6:42 PM, chitselb wrote:
>>> If I were to hazard a guess, state-smart words did two things instead of one, which was very unForthy. Also they had to be immediate, and were less reusable.
>>
>> Reusable? Can you explain that?
>>
>> --
>>
>> Rick
>
> Not good for reuse... hmm... Well, when is the last time you invoked something like this in a definition?
>
> [COMPILE] {some-immediate-word}
I'm not following you... I'm asking for an explanation of what you mean.
--
Rick
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web