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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-27 16:23 +0000 |
| Message-ID | <2015May27.182324@mips.complang.tuwien.ac.at> |
| In reply to | #39358 |
rickman <gnuarm@gmail.com> writes:
>BTW, I haven't seen the character notation 'A' before. Is that done in
>number? I take it this is not part of the ANS standard?
This is Forth-2012, and yes, this is done in the number conversion
part of the text interpreter.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-27 12:39 -0400 |
| Message-ID | <mk4rsu$m03$1@dont-email.me> |
| In reply to | #39359 |
On 5/27/2015 12:23 PM, Anton Ertl wrote: > rickman <gnuarm@gmail.com> writes: >> BTW, I haven't seen the character notation 'A' before. Is that done in >> number? I take it this is not part of the ANS standard? > > This is Forth-2012, and yes, this is done in the number conversion > part of the text interpreter. I found the routine to convert it in W32Forth and just now found it in the standard as <cnum>. Nice addition. A lot of the additions to VHDL have to do with day to day usage issues. Things that just make the language easier to use. This is a nice one for forth. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-27 22:14 +0200 |
| Message-ID | <5566258f$0$2923$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39352 |
Anton Ertl wrote: > This is Forth, and in Forth it's the same data type. May be you missed this QUOTE from the ANS Forth standard: "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." For all purposes: what a comparison operator returns is a BOOLEAN, not a number, not a mask, a BOOLEAN. Surprise, surprise, we AND (bit operation) and add (number) it. I've always stated I think it is a great lack in Forth, we don't have C equivalents of & and && (or | vs. ||). The only thing I can condone the use of a bit operator with flags if both are fully qualified flags. ANS Forth standard: "While Forth words which test flags accept any non-null bit pattern as true, there exists the concept of the well-formed flag." Followed by: " .. the following words are valid for operations on one or more flag data residing on the data stack: AND OR XOR INVERT" Read: one or more FLAGS - not a mixture of flags and cells or whatever. Note you can do the same thing with 2-complement by adding "1- INVERT" for 1-based flags - which makes very clear we're doing some conversion. Even better when you put it in a word, which is named in such a way the operation becomes clear, e.g. >MASK. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-27 17:13 -0400 |
| Message-ID | <mk5c0b$re4$1@dont-email.me> |
| In reply to | #39361 |
On 5/27/2015 4:14 PM, Hans Bezemer wrote: > Anton Ertl wrote: > >> This is Forth, and in Forth it's the same data type. > > May be you missed this QUOTE from the ANS Forth standard: > > "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." > > For all purposes: what a comparison operator returns is a BOOLEAN, not a > number, not a mask, a BOOLEAN. Surprise, surprise, we AND (bit operation) > and add (number) it. > > I've always stated I think it is a great lack in Forth, we don't have C > equivalents of & and && (or | vs. ||). The only thing I can condone the use > of a bit operator with flags if both are fully qualified flags. ANS Forth > standard: > > "While Forth words which test flags accept any non-null bit pattern as true, > there exists the concept of the well-formed flag." > > Followed by: > > " .. the following words are valid for operations on one or more flag data > residing on the data stack: AND OR XOR INVERT" > > Read: one or more FLAGS - not a mixture of flags and cells or whatever. I think you are reading what you wish to read... 6.1.0720 AND CORE ( x 1 x 2 –– x 3 ) x 3 is the bit-by-bit logical “and” of x 1 with x 2 AND is not intended to be solely a logical operator. What are the boolean operators in Forth other than perhaps 0= ? > Note you can do the same thing with 2-complement by adding "1- INVERT" for > 1-based flags - which makes very clear we're doing some conversion. Even > better when you put it in a word, which is named in such a way the > operation becomes clear, e.g. >MASK. I have discussed the issue of data typing many times in the VHDL language. In VHDL strong typing is enforced and the language uses overloading to allow operators to be transparently defined for a variety of combinations of input and output types. In such an environment typing helps to prevent obscure errors caused by mixing data types without regard to the implications. This is primarily for the type of user who is not so proficient with programming and needs help. It also imposes considerable overhead both in the tools to enforce the strong typing and in the programmer work to write code to do what is intended while avoiding the error reports (and the tool refusing to produce a design). In the context of the Forth language where so much more is incumbent on the programmer to know and understand, I think data typing is much less useful. I can't remember the last time I had a problem from mixing data types. Forth is a language which (as is often pointed out by Hugh) there are few data structures and corresponding operators. If I need to design my own arrays, then I think I can handle mixing of Boolean and integer data types. I think you are getting wrapped around the philosophical axle on this one. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-27 23:36 +0200 |
| Message-ID | <556638f3$0$2903$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39362 |
rickman wrote: > I think you are reading what you wish to read... I think it's stated pretty clear. Of course, if you don't want it to be true, it is entirely possible to read there what you want to read. > In the context of the Forth language where so much more is incumbent on > the programmer to know and understand, I think data typing is much less > useful. I can't remember the last time I had a problem from mixing data > types. Forth is a language which (as is often pointed out by Hugh) > there are few data structures and corresponding operators. If I need to > design my own arrays, then I think I can handle mixing of Boolean and > integer data types. If there are no aids or means to prevent you to do stupid things, it boils down to the discipline of the programmer. Note that arrays are arrays of "something", so any element of it can be used with any "something" operator. I even used a Harvard architecture to make perfectly clear there are basic datatypes. This even becomes more prominent when datatypes become more abstract like floats. There are many possible float formats which work equally well with a high level float library. Try mixing those with any more basic datatype (like cells) and see where that takes you. Why should mixing of other, more concrete datatypes be any different? > I think you are getting wrapped around the philosophical axle on this one. No, it's about clean design and not "ad hoc" decisions to handle any random issue you have at hand and try to hide it under a veil of "pragmatism" (which is a philosophical concept and needs a philosopher to apply properly). Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-27 18:06 -0400 |
| Message-ID | <mk5f2n$c9s$1@dont-email.me> |
| In reply to | #39367 |
On 5/27/2015 5:36 PM, Hans Bezemer wrote: > rickman wrote: >> I think you are reading what you wish to read... > I think it's stated pretty clear. Of course, if you don't want it to be > true, it is entirely possible to read there what you want to read. You seem to have stopped discussing the actual point totally. I quoted the relevant portion of the ANS spec and you snipped it in your reply. The AND operator is not a boolean operator only. It is a bitwise AND of the bits in two values. This can be used on boolean data, integer data or any other data type. >> In the context of the Forth language where so much more is incumbent on >> the programmer to know and understand, I think data typing is much less >> useful. I can't remember the last time I had a problem from mixing data >> types. Forth is a language which (as is often pointed out by Hugh) >> there are few data structures and corresponding operators. If I need to >> design my own arrays, then I think I can handle mixing of Boolean and >> integer data types. > If there are no aids or means to prevent you to do stupid things, it boils > down to the discipline of the programmer. Note that arrays are arrays > of "something", so any element of it can be used with any "something" > operator. I even used a Harvard architecture to make perfectly clear there > are basic datatypes. > > This even becomes more prominent when datatypes become more abstract like > floats. There are many possible float formats which work equally well with > a high level float library. Try mixing those with any more basic datatype > (like cells) and see where that takes you. Why should mixing of other, more > concrete datatypes be any different? I have no idea what you are trying to say here. I believe that in IEEE floating point a word with all zero bits is a floating point zero. If it is the same size as a cell, then it would work perfectly well to AND a floating point quantity with a flag to conditionally add it to another value. >> I think you are getting wrapped around the philosophical axle on this one. > No, it's about clean design and not "ad hoc" decisions to handle any random > issue you have at hand and try to hide it under a veil of "pragmatism" > (which is a philosophical concept and needs a philosopher to apply > properly). You have your opinion of what constitutes "clean" design and others have theirs. People have explained why they feel it's ok to use a well defined boolean value as defined in the Forth specification in a numeric operation. You don't agree with that and in fact, don't like the value of TRUE in the Forth spec, so your Forth has a difference from the standard. Ok, nice discussing it all. :) -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-29 10:35 +0200 |
| Message-ID | <556824c2$0$2849$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39368 |
rickman wrote: > I have no idea what you are trying to say here. I believe that in IEEE > floating point a word with all zero bits is a floating point zero. If > it is the same size as a cell, then it would work perfectly well to AND > a floating point quantity with a flag to conditionally add it to another > value. Exactly my point. When I talk of "floating point" all you can come up with is IEEE fp. Note there is *NOTHING* in the standard (and I hope there will never be) that says that an fp == IEEE fp. It's a completely abstract datatype. E.g. in Zen float, a float is represented by two cells: <mantissa><exponent>. In Brad Eckerts float it is three cells, an unsigned double and an exponent with sign bit - high level and entirely ANS standard. That's why it is a fallacy to do any operation between a float and any other datatype - at least without any carnal knowledge. The low level words (e.g. FSIN, FEXP, FSQRT, etc.) usually cannot or very difficultly or inefficiently be done without carnal knowledge, however, once you get past that, it's standard programs all the way. So yes, there is a level of abstraction you have to observe. By committing to a certain implementation technique - however common - you disregard this level of abstraction, making the standard as a whole weaker and less future proof. Even the ANS-94 standard has certain implementation techniques there that make it weak - which results in putting entire compiler families (cross compilers) outside the standard. I know this is a Forth tradition, but I can't say I tend to agree. It always makes the impression on me that Forthers are more mechanics than car designers - fixing "the problem" instead of taking a step back and solve it fundamentally. To make this more tangible, take a look at Discovery channel and compare how "Wheeler Dealers" solve things compared to "Fast 'n Loud". It's this difference I'm talking about. If you don't see any difference, there you have the difference, BTW. On the other hand, ANS-94 fixed many fallacies introduced in Forth-83 (like the size of a cell or a char), so I have mixed feelings about it. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-29 12:16 +0100 |
| Message-ID | <mk9hni$ck8$1@dont-email.me> |
| In reply to | #39401 |
on 29/05/2015 09:35:16, Hans Bezemer wrote: > rickman wrote: >> I have no idea what you are trying to say here. I believe that in IEEE >> floating point a word with all zero bits is a floating point zero. If >> it is the same size as a cell, then it would work perfectly well to AND >> a floating point quantity with a flag to conditionally add it to another >> value. > Exactly my point. When I talk of "floating point" all you can come up > with is IEEE fp. Note there is *NOTHING* in the standard (and I hope > there will never be) that says that an fp == IEEE fp. It's a > completely abstract datatype. Have you read section 12? http://lars.nocrew.org/dpans/dpans12.htm#12.1 "IEEE floating-point number: A single- or double-precision floating-point number as defined in ANSI/IEEE 754-1985." This has been in the standard for 20 years.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-29 09:42 -0400 |
| Message-ID | <mk9qao$9te$1@dont-email.me> |
| In reply to | #39406 |
On 5/29/2015 7:16 AM, Alex McDonald wrote: > on 29/05/2015 09:35:16, Hans Bezemer wrote: >> rickman wrote: >>> I have no idea what you are trying to say here. I believe that in IEEE >>> floating point a word with all zero bits is a floating point zero. If >>> it is the same size as a cell, then it would work perfectly well to AND >>> a floating point quantity with a flag to conditionally add it to another >>> value. >> Exactly my point. When I talk of "floating point" all you can come up >> with is IEEE fp. Note there is *NOTHING* in the standard (and I hope >> there will never be) that says that an fp == IEEE fp. It's a >> completely abstract datatype. > > Have you read section 12? http://lars.nocrew.org/dpans/dpans12.htm#12.1 > "IEEE floating-point number: A single- or double-precision floating-point > number as defined in ANSI/IEEE 754-1985." This has been in the standard > for 20 years. 12.3.1.2 Floating-point numbers The internal representation of a floating-point number, including the format and precision of the significand and the format and range of the exponent, is implementation defined. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-29 16:16 +0200 |
| Message-ID | <556874b0$0$2881$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39406 |
Alex McDonald wrote:
> on 29/05/2015 09:35:16, Hans Bezemer wrote:
>> rickman wrote:
>>> I have no idea what you are trying to say here. I believe that in IEEE
>>> floating point a word with all zero bits is a floating point zero. If
>>> it is the same size as a cell, then it would work perfectly well to AND
>>> a floating point quantity with a flag to conditionally add it to another
>>> value.
>> Exactly my point. When I talk of "floating point" all you can come up
>> with is IEEE fp. Note there is *NOTHING* in the standard (and I hope
>> there will never be) that says that an fp == IEEE fp. It's a
>> completely abstract datatype.
> Have you read section 12? http://lars.nocrew.org/dpans/dpans12.htm#12.1
> "IEEE floating-point number: A single- or double-precision floating-point
> number as defined in ANSI/IEEE 754-1985." This has been in the standard
> for 20 years.
Yes, sorry to spoil the fun: this is only the case with SINGLE or DOUBLE
precision fp's. The DF! and SF! families of this world, you know..
Otherwise:
12.3.1.2 Floating-point numbers
The internal representation of a floating-point number, including the
format and precision of the significand and the format and range of the
exponent, is implementation defined. Any rounding or truncation of
floating-point numbers is implementation defined.
Oh, how devious to read selectively.. ;-)
Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-29 15:24 +0100 |
| Message-ID | <mk9sok$lep$3@dont-email.me> |
| In reply to | #39414 |
on 29/05/2015 15:16:24, Hans Bezemer wrote: > Alex McDonald wrote: > >> on 29/05/2015 09:35:16, Hans Bezemer wrote: >>> rickman wrote: >>>> I have no idea what you are trying to say here. I believe that in IEEE >>>> floating point a word with all zero bits is a floating point zero. If >>>> it is the same size as a cell, then it would work perfectly well to AND >>>> a floating point quantity with a flag to conditionally add it to another >>>> value. >>> Exactly my point. When I talk of "floating point" all you can come up >>> with is IEEE fp. Note there is *NOTHING* in the standard (and I hope >>> there will never be) that says that an fp == IEEE fp. It's a >>> completely abstract datatype. > >> Have you read section 12? http://lars.nocrew.org/dpans/dpans12.htm#12.1 >> "IEEE floating-point number: A single- or double-precision floating-point >> number as defined in ANSI/IEEE 754-1985." This has been in the standard >> for 20 years. > Yes, sorry to spoil the fun: this is only the case with SINGLE or > DOUBLE precision fp's. The DF! and SF! families of this world, you > know.. > > Otherwise: > > 12.3.1.2 Floating-point numbers > The internal representation of a floating-point number, including the > format and precision of the significand and the format and range of > the exponent, is implementation defined. Any rounding or truncation of > floating-point numbers is implementation defined. > > Oh, how devious to read selectively.. ;-) > > Hans Bezemer > > Good point; I missed that.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <fork@lllljunkqwer.cpm> |
|---|---|
| Date | 2015-05-27 17:32 -0400 |
| Message-ID | <op.xzbcr8uhwhxjl4@localhost> |
| In reply to | #39361 |
On Wed, 27 May 2015 16:14:11 -0400, Hans Bezemer <the.beez.speaks@gmail.com> wrote: > I've always stated I think it is a great lack in Forth, we > don't have C equivalents of & and && (or | vs. ||). What would your definitions be for those? E.g., this is probably bad Forth, yes? (FYI, untested.) : && 0= 0= SWAP 0= 0= AND ; : || 0= 0= SWAP 0= 0= OR ; How about? (Also, untested.) : && 0= SWAP 0= OR 0= ; : || 0= SWAP 0= AND 0= ; Rod Pemberton -- If fewer guns reduced murders, how does one explain Moscow, Chicago, New York, and South Africa?
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-05-27 23:59 +0200 |
| Message-ID | <i6qc6aqg19pa$.1e326iy7ip7pn.dlg@40tude.net> |
| In reply to | #39364 |
Op Wed, 27 May 2015 17:32:22 -0400 schreef Rod Pemberton: > On Wed, 27 May 2015 16:14:11 -0400, Hans Bezemer > <the.beez.speaks@gmail.com> wrote: > >> I've always stated I think it is a great lack in Forth, we >> don't have C equivalents of & and && (or | vs. ||). > > What would your definitions be for those? > > E.g., this is probably bad Forth, yes? (FYI, untested.) > >: && 0= 0= SWAP 0= 0= AND ; > :|| 0= 0= SWAP 0= 0= OR ; > > How about? (Also, untested.) > >: && 0= SWAP 0= OR 0= ; > :|| 0= SWAP 0= AND 0= ; > > > Rod Pemberton Another possibility is \ Continue current defintion when the condition is true, \ otherwise leave with false flag : && 0= if rdrop false then ; ( flag -- | false ) \ Continue current defintion when the condition is false, \ otherwise leave with a true flag : || if rdrop true then ; ( flag -- | true ) Examples: \ Shortcut fail when test1 is already false ... test1 && test2 && test3 ... \ Shortcut succeed when test1 is already true ... test1 || test2 || test3 ... -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-27 19:31 -0400 |
| Message-ID | <mk5k2n$sck$1@dont-email.me> |
| In reply to | #39369 |
On 5/27/2015 5:59 PM, Coos Haak wrote: > Op Wed, 27 May 2015 17:32:22 -0400 schreef Rod Pemberton: > >> On Wed, 27 May 2015 16:14:11 -0400, Hans Bezemer >> <the.beez.speaks@gmail.com> wrote: >> >>> I've always stated I think it is a great lack in Forth, we >>> don't have C equivalents of & and && (or | vs. ||). >> >> What would your definitions be for those? >> >> E.g., this is probably bad Forth, yes? (FYI, untested.) >> >> : && 0= 0= SWAP 0= 0= AND ; >> :|| 0= 0= SWAP 0= 0= OR ; >> >> How about? (Also, untested.) >> >> : && 0= SWAP 0= OR 0= ; >> :|| 0= SWAP 0= AND 0= ; >> >> >> Rod Pemberton > > Another possibility is > \ Continue current defintion when the condition is true, > \ otherwise leave with false flag > : && 0= if rdrop false then ; ( flag -- | false ) > > \ Continue current defintion when the condition is false, > \ otherwise leave with a true flag > : || if rdrop true then ; ( flag -- | true ) I assume you are trying to duplicate the way in C logical operators stop evaluating when the result is determined. This will only work if used at the end of a definition or at least the final && testx is followed by an IF. > Examples: > \ Shortcut fail when test1 is already false > .... test1 && test2 && test3 ... ... test1 && test2 && test3 || test4 ... This will not evaluate test4 if any of the first three tests are false. > \ Shortcut succeed when test1 is already true > .... test1 || test2 || test3 ... > -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-05-27 23:11 -0700 |
| Message-ID | <0780a318-3d90-44a2-b26b-4dab45b95e15@googlegroups.com> |
| In reply to | #39364 |
joi, 28 mai 2015, 00:32:11 UTC+3, Rod Pemberton a scris: > On Wed, 27 May 2015 16:14:11 -0400, Hans Bezemer > <the.beez.speaks@gmail.com> wrote: > > > I've always stated I think it is a great lack in Forth, we > > don't have C equivalents of & and && (or | vs. ||). > > What would your definitions be for those? > > E.g., this is probably bad Forth, yes? (FYI, untested.) > > : && 0= 0= SWAP 0= 0= AND ; > : || 0= 0= SWAP 0= 0= OR ; > > How about? (Also, untested.) > > : && 0= SWAP 0= OR 0= ; > : || 0= SWAP 0= AND 0= ; > > > Rod Pemberton > -- > If fewer guns reduced murders, how does one explain > Moscow, Chicago, New York, and South Africa? Or probably you should have a 0<> primitive, which seems very important in this context. Then: : && 0<> swap 0<> and ; : || 0<> swap 0<> or ; && and || can be much more efficient if done in assembly/C. Also, I think 0= should be synonymed with NOT Or, in a new dialect, the bitwise operators may be called %AND %OR %XOR %NOT (if the % would be a prefix for binary literals). and the logical ones AND OR XOR NOT. This would be a forth dialect of course, or how Rick says, it would not be forth anyhow.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-28 12:21 +0100 |
| Message-ID | <mk6tm3$lat$1@dont-email.me> |
| In reply to | #39361 |
on 27/05/2015 21:14:06, Hans Bezemer wrote: > Anton Ertl wrote: > >> This is Forth, and in Forth it's the same data type. > > May be you missed this QUOTE from the ANS Forth standard: > > "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." > > For all purposes: what a comparison operator returns is a BOOLEAN, not > a number, not a mask, a BOOLEAN. Surprise, surprise, we AND (bit > operation) and add (number) it. Casting a boolean TRUE or FALSE to an all bits set or all bits unset mask is, *by definition in the standard*, a noop. : >MASK ; IMMEDIATE. Therefore bit operations are possible without converting between data types; as are numeric operations (the code assumes 2s complement). > > I've always stated I think it is a great lack in Forth, we don't have > C equivalents of & and && (or | vs. ||). The only thing I can condone > the use of a bit operator with flags if both are fully qualified > flags. ANS Forth standard: > > "While Forth words which test flags accept any non-null bit pattern as > true, there exists the concept of the well-formed flag." > > Followed by: > > " .. the following words are valid for operations on one or more flag > data residing on the data stack: AND OR XOR INVERT" > > Read: one or more FLAGS - not a mixture of flags and cells or > whatever. It is clear from the context that AND OR XOR and INVERT can, *in addition to doing bitwise operations*, be used on flags. Well formed or otherwise. Because : >MASK ; IMMEDIATE. > > Note you can do the same thing with 2-complement by adding "1- INVERT" > for 1-based flags - which makes very clear we're doing some > conversion. Even better when you put it in a word, which is named in > such a way the operation becomes clear, e.g. >MASK. : >MASK ; IMMEDIATE : >FLAG 0= 0= ; \ 2s complement only > > Hans Bezemer >
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-28 12:24 +0100 |
| Message-ID | <mk6tr3$ltj$1@dont-email.me> |
| In reply to | #39377 |
on 28/05/2015 12:21:44, "Alex McDonald" wrote: >: >FLAG 0= 0= ; \ 2s complement only > Asleep. That should be : FLAG 0<> ; \ any complement
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-05-29 10:53 +0200 |
| Message-ID | <556828ef$0$2849$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #39377 |
Alex McDonald wrote: > It is clear from the context that AND OR XOR and INVERT can, *in addition > to doing bitwise operations*, be used on flags. Well formed or otherwise. No, well-formed flags. In some cases you might get away with it (using only one well formed flag), but you're taking risks - unless you got your head well wrapped around it. E.g. 2 -1 AND (works, but not 2 4 AND) 15 INVERT (0= works much more consistent) 1 5 OR (always works) 15 -1 XOR (rarely used in a logical sense, but I can't see it working unless with well-formed flags) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-29 12:19 +0100 |
| Message-ID | <mk9hu4$d8f$1@dont-email.me> |
| In reply to | #39403 |
on 29/05/2015 09:53:08, Hans Bezemer wrote: > Alex McDonald wrote: >> It is clear from the context that AND OR XOR and INVERT can, *in addition >> to doing bitwise operations*, be used on flags. Well formed or otherwise. > No, well-formed flags. In some cases you might get away with it (using > only one well formed flag), but you're taking risks - unless you got > your head well wrapped around it. > > E.g. > > 2 -1 AND (works, but not 2 4 AND) > 15 INVERT (0= works much more consistent) > 1 5 OR (always works) > 15 -1 XOR (rarely used in a logical sense, but I can't see it working > unless with well-formed flags) > > Hans Bezemer > > > Who said and where does it say that the result was a well formed flag?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-29 13:51 +0000 |
| Message-ID | <2015May29.155142@mips.complang.tuwien.ac.at> |
| In reply to | #39361 |
Hans Bezemer <the.beez.speaks@gmail.com> writes:
>Anton Ertl wrote:
>
>> This is Forth, and in Forth it's the same data type.
>
>May be you missed this QUOTE from the ANS Forth standard:
>
>"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."
No, I did not miss that. But you missed that the types in standard
Forth do not have the restrictions you would like them to have.
|3.1.3.1 Flags
|
|[...] A true flag returned by a standard word shall be a single-cell value
|with all bits set. A false flag returned by a standard word shall be a
|single-cell value with all bits clear.
>For all purposes: what a comparison operator returns is a BOOLEAN, not a
>number, not a mask, a BOOLEAN.
No, what a comparison operator returns is a (well-formed) flag; and a
well-formed flag has a bit-pattern that can be used as a mask.
Forth is not Pascal, or Algol or wherever you have "BOOLEAN" from.
>"While Forth words which test flags accept any non-null bit pattern as true,
>there exists the concept of the well-formed flag."
>
>Followed by:
>
>" .. the following words are valid for operations on one or more flag data
>residing on the data stack: AND OR XOR INVERT"
>
>Read: one or more FLAGS - not a mixture of flags and cells or whatever.
This statement in the informative (not normative) part of the standard
states some of the cases for which theese words are valid, but is not
exhaustive. You can look in the normative part of the standard what
these words actually do. E.g.,:
|6.1.0720 AND CORE
| ( x1 x2 x3 )
| x3 is the bit-by-bit logical "and" of x1 with x2.
BTW, I find your definition of a different, but still documented
numeric value for TRUE in your 4th to be not congruent with your
strongly-typed attitude. I see a number of options that are more in
your spirit.
1) Static type checking.
2) Dynamic type checking.
3) TRUE and FALSE are represented by arbitrary (but different) bit
patterns (possibly different at every session), flags can be combined
only with NOT and your && and || (which only take and only produce
TRUE and FALSE), and IF, UNTIL, etc. work only when you pass them
either TRUE or FALSE; AND OR INVERT 0= cannot be used for flags in
that scheme.
4) TRUE and FALSE are arbitrary (but different) bit patterns, where
certain bits are 0 for FALSE and 1 for TRUE, and IF UNTIL etc. check
(only) these bits (the bit patterns and the checked bits may differ
from session to session). In this scheme AND OR INVERT can be used
for flags, but 0= cannot.
In none of these schemes flags can be used reliably as masks, nor can
you do "( n ) IF" (instead use "( n ) 0<> IF").
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web