Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37787 > unrolled thread
| Started by | hughaguilar96@gmail.com |
|---|---|
| First post | 2015-03-31 15:13 -0700 |
| Last post | 2015-07-06 12:47 -0400 |
| Articles | 20 on this page of 509 — 42 participants |
Back to article view | Back to comp.lang.forth
bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-03-31 15:13 -0700
Re: bug in VFX --- IF does't work jfong@ms4.hinet.net - 2015-03-31 20:55 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-01 11:26 +0000
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-01 08:39 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-01 17:35 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 15:18 -0700
Re: bug in VFX --- IF does't work Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-02 10:35 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-02 10:08 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-01 12:33 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-01 22:16 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-01 13:40 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-02 17:07 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-02 19:18 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-03 06:43 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-03 10:49 -0700
Re: bug in VFX --- IF does't work beeflo <beeflobill@gmail.com> - 2015-04-03 11:17 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 14:35 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 19:42 +0100
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-03 14:34 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 20:52 -0400
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-04 03:47 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 14:07 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-05 00:11 -0400
Re: bug in VFX --- IF does't work jkn_gg@nicorp.f9.co.uk - 2015-04-05 08:11 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-03 23:50 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 05:44 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-03 21:32 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-04 17:03 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-04 21:56 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-05 18:11 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-05 10:13 -0700
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-06 14:03 +0200
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-06 14:44 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-07 11:02 +0200
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-07 17:21 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-07 16:02 +0000
Re: bug in VFX --- IF does't work Paul Rubin <no.email@nospam.invalid> - 2015-04-07 11:06 -0700
Re: bug in VFX --- IF does't work Elizabeth D Rather <erather@forth.com> - 2015-04-03 18:52 -1000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-05 03:54 +0000
Re: bug in VFX --- IF does't work Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2015-04-05 18:21 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:47 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 14:41 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-12 23:20 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-12 18:40 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-13 04:36 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 23:12 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-14 09:53 -0400
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-14 18:38 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-15 21:03 +0100
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-15 19:38 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:54 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-16 10:01 +0100
Re: bug in VFX --- IF does't work Michael Barry <barrym95838@yahoo.com> - 2015-06-16 18:25 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-17 10:11 +0100
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:49 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-15 21:56 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-16 00:11 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-16 07:21 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-16 19:45 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-17 10:34 +0000
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-17 08:49 -0700
Re: bug in VFX --- IF does't work mhx@iae.nl - 2015-06-17 13:50 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-17 18:36 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-17 23:44 -0700
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-06-17 21:14 -1000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-18 00:15 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 09:27 +0100
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 02:04 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-18 03:32 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 04:19 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-18 12:31 +0000
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 05:57 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-18 12:21 +0000
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-06-18 08:01 -1000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 12:11 -0700
Re: bug in VFX --- IF does't work Walter Banks <walter@bytecraft.com> - 2015-06-18 17:25 -0400
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-18 22:56 +0200
Re: bug in VFX --- IF does't work coos <chforth@hccnet.nl> - 2015-06-18 18:54 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 10:53 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 21:31 +0100
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-18 23:58 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-19 08:23 +0100
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 01:01 -0700
Re: bug in VFX --- IF does't work Thomas Östreicher <thomas.oestreicher@gmail.com> - 2015-06-19 01:07 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 09:38 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 02:51 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:35 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-20 21:28 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-20 21:33 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-20 21:49 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:01 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:19 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 13:16 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 16:53 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 15:39 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 18:11 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 22:16 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 23:26 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 03:23 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 08:04 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 14:46 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 13:03 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-24 15:05 +0100
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 14:32 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 14:20 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 20:04 +0200
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-24 16:08 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 08:07 +0100
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-26 08:55 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 00:56 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 18:06 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 01:00 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-27 11:07 +0100
Re: bug in VFX --- IF does't work Matthias Trute <matthias.trute@gmail.com> - 2015-06-27 12:04 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 21:14 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:26 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-20 21:55 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:26 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-22 00:29 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 03:24 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 07:49 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-21 21:16 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-22 02:09 -0700
Re: bug in VFX --- IF does't work "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-22 05:57 -0400
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:27 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 11:58 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 01:04 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:17 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:55 -0700
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-19 02:42 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-19 03:56 -0400
Re: bug in VFX --- IF does't work Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-19 02:47 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 11:37 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-19 19:56 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-21 21:23 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 08:39 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-22 11:27 +0100
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-22 16:07 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:56 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-19 00:40 -0700
Re: bug in VFX --- IF does't work Ron Aaron <rambamist@gmail.com> - 2015-06-19 10:55 +0300
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 14:43 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-06-22 02:05 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 16:41 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-19 12:55 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-18 10:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-18 20:56 +0100
Re: bug in VFX --- IF does't work Hannu Vuolasaho <vuokkosetae@gmail.com> - 2015-06-19 03:13 +0300
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-19 08:37 +0100
WAS: bug in VFX... IS: More rants from Rantman of Rantland rickman <gnuarm@gmail.com> - 2015-06-18 16:33 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 05:19 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-06-19 13:38 +0100
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland rickman <gnuarm@gmail.com> - 2015-06-19 12:29 -0400
Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-19 17:53 -0400
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-19 12:07 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-19 12:55 +0000
The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 15:36 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-20 14:01 -0400
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-20 08:33 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-20 21:18 -0700
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-21 13:09 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-21 14:50 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-21 23:58 +0200
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 10:54 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 15:52 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 17:08 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:43 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-22 20:19 +0200
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 08:47 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 13:58 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-22 15:37 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-22 17:02 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:29 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 18:18 +0000
Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) Mark Wills <markwills1970@gmail.com> - 2015-06-23 00:42 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-22 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-23 02:42 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-23 03:38 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 12:55 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-23 06:55 -0700
Re: The meaning of xt in Forth-94 peter.m.falth@gmail.com - 2015-06-23 08:29 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 16:47 +0000
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-23 22:48 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-24 18:13 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-25 13:40 +0100
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-25 06:29 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-25 08:13 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-25 16:33 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-25 13:45 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-26 05:54 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-06-27 21:08 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-26 03:44 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-26 03:52 -0700
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-06-26 08:54 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 01:09 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-27 11:00 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 15:23 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-27 16:31 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-27 21:11 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 13:41 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-29 03:09 +0200
Re: The meaning of xt in Forth-94 mhx@iae.nl - 2015-06-27 06:42 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-28 13:21 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-06-26 12:20 +0100
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-12 19:43 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 14:09 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-28 10:21 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 14:26 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-29 03:21 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-30 07:14 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-01 00:33 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 13:58 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 00:18 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:33 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 08:28 +0100
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-07-05 12:22 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 16:03 +0000
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-06 18:40 +0100
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-07-06 20:36 +0000
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-07 07:18 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:17 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-06-28 19:32 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-28 19:32 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-06-29 15:06 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-30 07:48 +0000
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-06-30 03:38 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-30 04:44 -0700
Re: The meaning of xt in Forth-94 franck.bensusan@gmail.com - 2015-07-01 02:49 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-01 04:43 -0700
Re: The meaning of xt in Forth-94 rickman <gnuarm@gmail.com> - 2015-07-02 02:16 -0400
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-01 23:24 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-02 00:10 -0700
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-02 01:51 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-02 12:49 +0000
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-02 18:02 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:31 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-30 01:55 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-01 20:32 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-02 02:40 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-02 22:40 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 04:32 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 03:03 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-03 03:16 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:06 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-03 22:39 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-04 14:45 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-04 11:39 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 19:55 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-04 20:54 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 07:18 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-04 21:47 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 01:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 10:30 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 03:09 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 16:29 +0100
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-05 09:49 -0700
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 22:10 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 14:54 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 12:41 -1000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 15:47 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 00:57 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 16:08 -0700
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-06 01:36 +0200
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-05 17:25 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 13:15 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 02:05 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-05 19:46 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-06 07:57 +0000
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-06 18:53 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 07:37 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 05:18 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-08 07:59 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-08 12:06 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-08 20:08 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-09 08:31 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:06 +0100
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 14:09 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-09 13:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 20:27 +0100
Re: The meaning of xt in Forth-94 Paul Rubin <no.email@nospam.invalid> - 2015-07-10 12:46 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-10 21:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 17:02 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 17:48 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 20:58 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-08 20:19 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-08 21:48 +0200
Re: The meaning of xt in Forth-94 "Alex McDonald" <blog@rivadpm.com> - 2015-07-09 00:47 +0100
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-09 04:56 +0000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-11 14:34 -0700
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 08:09 +0100
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 16:32 +0200
Re: The meaning of xt in Forth-94 coos <chforth@hccnet.nl> - 2015-07-07 16:43 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 15:16 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-07 22:14 +0200
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-08 02:06 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-07 14:57 +0000
Re: The meaning of xt in Forth-94 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-07-07 22:51 +0100
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-07 13:11 -1000
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-07 19:34 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-06 20:47 -0700
Re: The meaning of xt in Forth-94 hughaguilar96@gmail.com - 2015-07-06 21:55 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-07-05 08:53 -1000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:56 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-23 18:13 -0400
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 01:44 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 20:07 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-25 17:05 +0000
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 02:08 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 04:53 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 04:57 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 05:46 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 07:05 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 14:40 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 10:12 -0700
Re: The meaning of xt in Forth-94 stephen@mpeforth.com (Stephen Pelc) - 2015-06-24 20:35 +0000
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-24 15:01 +0000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 08:58 -0700
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-24 09:54 -0700
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-28 16:40 +0000
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-28 15:10 -0400
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-28 23:32 -0700
Re: The meaning of xt in Forth-94 "Elizabeth D. Rather" <erather@forth.com> - 2015-06-28 21:37 -1000
Re: The meaning of xt in Forth-94 Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-06-29 01:38 -0700
Re: The meaning of xt in Forth-94 Mark Wills <markwills1970@gmail.com> - 2015-06-24 08:53 -0700
Re: The meaning of xt in Forth-94 "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-06-24 20:08 -0400
Re: The meaning of xt in Forth-94 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 10:30 +0000
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 22:58 +0200
Re: The meaning of xt in Forth-94 Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-23 23:49 +0200
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-06-19 15:07 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-20 16:09 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-22 16:24 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 17:41 +0000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 16:54 +0000
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-15 22:57 -0400
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-13 10:51 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-06-13 12:57 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 21:53 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-13 22:41 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 11:42 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 09:26 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 23:15 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 16:39 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 15:21 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-06-14 23:20 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 16:48 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 17:52 -0700
Re: bug in VFX --- IF does't work Doug Hoffman <glidedog@gmail.com> - 2015-06-14 21:13 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-06-14 20:09 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-03 10:25 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-03 14:43 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 20:14 +0100
Re: bug in VFX --- IF does't work jfong@ms4.hinet.net - 2015-04-03 23:16 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-03 20:02 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-03 20:46 +0000
Re: bug in VFX --- IF does't work krishna.myneni@ccreweb.org - 2015-04-04 06:43 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-04 17:31 +0000
Re: bug in VFX --- IF does't work krishna.myneni@ccreweb.org - 2015-04-04 15:54 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 21:01 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-06 04:48 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-04 13:57 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-05 00:16 -0400
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-05 10:11 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 14:37 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-04-06 04:52 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:58 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-06 13:56 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-06 22:22 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-06 18:09 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-07 14:30 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-07 15:43 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-10 19:55 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-11 15:51 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-11 16:25 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-12 10:22 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 10:48 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 10:53 +0000
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-12 14:18 +0200
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-12 14:35 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-13 12:36 +0000
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-13 06:00 -0700
Re: bug in VFX --- IF does't work Coos Haak <chforth@hccnet.nl> - 2015-04-13 21:02 +0200
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-13 13:32 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 09:40 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-04-12 13:38 -0400
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-12 18:55 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-13 00:07 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-13 08:07 +0000
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 23:09 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-12 20:35 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-13 10:10 +0000
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-05-13 15:58 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-13 13:13 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-14 11:40 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-14 18:48 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-06-12 21:51 -0400
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-13 00:13 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 20:43 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-13 09:53 +0100
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-14 09:46 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-14 10:01 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-14 18:24 +0100
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-14 17:17 -0400
Re: bug in VFX --- IF does't work Ron Aaron <rambamist@gmail.com> - 2015-04-13 18:08 +0300
Re: bug in VFX --- IF does't work "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-06 22:07 -0400
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-04-06 16:44 -1000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-07 11:09 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-07 14:49 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-08 01:58 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-20 23:21 -0700
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-21 02:10 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-21 10:41 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 13:31 +0100
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-04-21 06:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 14:09 +0100
Re: bug in VFX --- IF does't work Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 10:59 +0200
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-22 11:41 +0000
Re: bug in VFX --- IF does't work Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 14:13 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 14:06 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-22 15:42 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-22 15:57 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 16:43 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-24 05:35 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 11:22 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 11:18 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-25 01:21 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-25 16:49 +0000
Re: bug in VFX --- IF does't work Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-05-03 21:07 +0100
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-03 23:25 +0100
Re: bug in VFX --- IF does't work gwj.nexus@gmail.com - 2015-05-05 10:53 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-05 19:10 +0100
Re: bug in VFX --- IF does't work Gerry <gerry@jackson9000.fsnet.co.uk> - 2015-05-06 21:41 +0100
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-07 11:05 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 11:35 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 14:09 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-04 03:08 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-04 09:23 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-04 20:32 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 13:26 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-06 20:00 +0200
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-06 13:24 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-08 12:07 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-08 18:26 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-09 01:10 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-12 16:13 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-13 00:11 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-04 16:58 +0000
Re: bug in VFX --- IF does't work gwj.nexus@gmail.com - 2015-05-05 11:24 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-06 13:13 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 13:11 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-25 21:05 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-21 14:06 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-22 20:05 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 05:57 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-04-23 10:50 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 11:59 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-05-12 23:18 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-12 20:24 -0700
Re: bug in VFX --- IF does't work "Elizabeth D. Rather" <erather@forth.com> - 2015-04-24 08:56 -1000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-24 12:09 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 22:29 +0100
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 17:54 +0000
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-02 09:04 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-02 21:04 -0700
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-03 10:48 +0000
Re: bug in VFX --- IF does't work Hans Bezemer <the.beez.speaks@gmail.com> - 2015-04-10 17:52 +0200
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-10 16:13 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-11 16:56 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-12 09:28 -0700
Re: bug in VFX --- IF does't work Jason Damisch <jasondamisch@yahoo.com> - 2015-04-03 10:26 -0700
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-04-05 21:54 -0700
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-26 01:20 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-26 15:09 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-04-27 03:13 +0200
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-01 14:59 +0000
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-05-01 19:38 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-01 16:59 -0700
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 15:56 +0000
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-01 22:45 +0200
Re: bug in VFX --- IF does't work JennyB <jennybrien@googlemail.com> - 2015-05-02 02:58 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-05-02 11:51 +0000
Re: bug in VFX --- IF does't work albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-02 12:25 +0000
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-02 16:45 +0000
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-05-02 19:12 +0100
Re: bug in VFX --- IF does't work anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-03 16:23 +0000
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-03 15:47 -0700
Re: bug in VFX --- IF does't work Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-05-04 10:11 +0100
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-05-04 09:16 -0700
Re: bug in VFX --- IF does't work roman.pavlyuk.0@gmail.com - 2015-05-04 10:15 -0700
Re: bug in VFX --- IF does't work "WJ" <w_a_x_man@yahoo.com> - 2015-06-15 23:35 +0000
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 02:31 -0700
Re: bug in VFX --- IF does't work stephen@mpeforth.com (Stephen Pelc) - 2015-07-02 17:20 +0000
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 15:40 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-02 19:55 -0400
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 19:43 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-02 23:08 -0400
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-02 21:56 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-03 01:25 -0400
Re: bug in VFX --- IF does't work hughaguilar96@gmail.com - 2015-07-02 23:00 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-03 22:25 +0100
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-03 00:50 -0700
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-03 18:21 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-04 13:09 +0100
Re: bug in VFX --- IF does't work Ching-Tang Tseng <ilikeforth@gmail.com> - 2015-07-04 15:01 -0700
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 08:49 +0100
Re: bug in VFX --- IF does't work Bernd Paysan <bernd.paysan@gmx.de> - 2015-07-05 15:23 +0200
Re: bug in VFX --- IF does't work "Alex McDonald" <blog@rivadpm.com> - 2015-07-05 15:56 +0100
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-05 12:21 -0400
Re: bug in VFX --- IF does't work Mark Wills <markwills1970@gmail.com> - 2015-07-06 01:45 -0700
Re: bug in VFX --- IF does't work rickman <gnuarm@gmail.com> - 2015-07-06 12:47 -0400
Page 16 of 26 — ← Prev page 1 … 14 15 [16] 17 18 … 26 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-06 21:55 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <6be08525-1898-4e2b-8aad-22be74ab3f15@googlegroups.com> |
| In reply to | #40380 |
On Monday, July 6, 2015 at 8:47:33 PM UTC-7, Raimond Dragomir wrote: > We are in 21st century, [aren't] we? This is a point I have made many many times --- a lot of Charles Moore's design for Forth was for 1970s vintage computers --- I don't think he ever intended this stuff to be written in stone as a standard and continue to be forced upon us in the year 2015. Examples are: 1.) PAD --- This was almost certainly a hack he did to get some application program working by deadline, because he didn't have time to implement a heap and/or his computer had an extreme memory shortage. 2.) DO loops --- The I and J are a half-step toward being local variables. This whole thing, especially how in clashes with >R and R>, is a gross hack that was needed in 1970s computers but should have become obsolescent in Forth-83 and been dropped from ANS-Forth. There are many other examples, but I don't have time right now to list them. My point is that Charles Moore got kicked out of Forth Inc., and then there weren't any programmers at Forth Inc. --- so they have been maintaining his 1970s Forth for decades --- they don't have the initiative or the ability to think up new ideas more fitting for the new computers, so they just hang onto the old ideas forever...
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-07-05 08:53 -1000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <OYadnU_deua-4ATInZ2dnUU7-dmdnZ2d@supernews.com> |
| In reply to | #40303 |
On 7/5/15 12:09 AM, Raimond Dragomir wrote: >>> So the behaviour is IF ( C: -- orig ) but C (control stack) may not >>> exist ?? >>> >> >> Yes; as you wrote above, this is the /behaviour/ of IF, not its >> implementation. >> > > > I really don't get it. IF is specified to put something on a stack which may > not exist... It most definitely exists. And you are advised that you should avoid use of the data stack until THEN consumes that orig (or one left by ELSE). If you really want to know definitively whether you can use the data stack on the particular Forth you're coding for, consult that system's documentation, which is required to tell you. ... >>> My main concern is the "data stack". All words in the Forth standard >>> (not C standard or any other standard) - FORTH standard - must give me >>> the data stack effect, because it's explicit. >>> >>> I don't care about the control stack, I care about data stack. You >>> seem to not understand this simple issue. Ok. If you want to know if the control flow stack is the data stack on the implementation you're using, consult its documentation. Otherwise, the safest assumption is that they are the same, at compile time. >> For the sake of argument, let's say we defined the control stack as the >> data stack. Then IF ( -- orig ) at compile time. Or we could mandate a >> separate control flow stack. Then IF ( -- c: orig ) at compile time. >> >> Which would you prefer? > > I prefer IF ( C: -- orig ) exactly like in standrad. Or if you prefer: > IF ( -- R: -- C: -- orig ) > > But it's not about which I prefer. It's about that the standard IF has > really undefined behaviour, regarding any stack at all. Because you can > have any situation. The bad thing is that it is not specified against > data stack and return stack. No, it's really about the preference of the implementer. If the implementer is you, do what you want. If it's someone else, s/he should have documented the choice. If the documentation doesn't tell you, the system is not in compliance with the standard. > If you really like to not have a control stack standardized, maybe: > IF ( -- R: -- ) should be a solution. Then you are allowed to do anything > you want to compile IF. The control stack may be or may not be, you can > do whatever you want, yet this IF is very clearly specified. And for the > behaviour you can write a literature about what IF is all about, like in C > or any other language. The vast majority of Forths put the control flow stack on the data stack, so it's always a safe bet to assume that's where it is. And it would be irresponsible to force all implementers to create a second stack if they don't want to. 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-07-06 01:56 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <85ddd819-8e29-44d4-bcd4-29311dfcd174@googlegroups.com> |
| In reply to | #40324 |
On Sunday, 5 July 2015 19:53:25 UTC+1, Elizabeth D. Rather wrote: > On 7/5/15 12:09 AM, Raimond Dragomir wrote: > >>> So the behaviour is IF ( C: -- orig ) but C (control stack) may not > >>> exist ?? > >>> > >> > >> Yes; as you wrote above, this is the /behaviour/ of IF, not its > >> implementation. > >> > > > > > > I really don't get it. IF is specified to put something on a stack which may > > not exist... > > It most definitely exists. And you are advised that you should avoid use > of the data stack until THEN consumes that orig (or one left by ELSE). > If you really want to know definitively whether you can use the data > stack on the particular Forth you're coding for, consult that system's > documentation, which is required to tell you. > > ... > >>> My main concern is the "data stack". All words in the Forth standard > >>> (not C standard or any other standard) - FORTH standard - must give me > >>> the data stack effect, because it's explicit. > >>> > >>> I don't care about the control stack, I care about data stack. You > >>> seem to not understand this simple issue. > > Ok. If you want to know if the control flow stack is the data stack on > the implementation you're using, consult its documentation. Otherwise, > the safest assumption is that they are the same, at compile time. > > >> For the sake of argument, let's say we defined the control stack as the > >> data stack. Then IF ( -- orig ) at compile time. Or we could mandate a > >> separate control flow stack. Then IF ( -- c: orig ) at compile time. > >> > >> Which would you prefer? > > > > I prefer IF ( C: -- orig ) exactly like in standrad. Or if you prefer: > > IF ( -- R: -- C: -- orig ) > > > > But it's not about which I prefer. It's about that the standard IF has > > really undefined behaviour, regarding any stack at all. Because you can > > have any situation. The bad thing is that it is not specified against > > data stack and return stack. > > No, it's really about the preference of the implementer. If the > implementer is you, do what you want. If it's someone else, s/he should > have documented the choice. If the documentation doesn't tell you, the > system is not in compliance with the standard. > > > If you really like to not have a control stack standardized, maybe: > > IF ( -- R: -- ) should be a solution. Then you are allowed to do anything > > you want to compile IF. The control stack may be or may not be, you can > > do whatever you want, yet this IF is very clearly specified. And for the > > behaviour you can write a literature about what IF is all about, like in C > > or any other language. > > The vast majority of Forths put the control flow stack on the data > stack, so it's always a safe bet to assume that's where it is. And it > would be irresponsible to force all implementers to create a second > stack if they don't want to. > > Cheers, > Elizabeth > Many ways to skin the cat. Forth is so flexible, you can get it to tell you if it is using the data stack as the control flow stack: (ensure stack is empty) : test 1 2 if [ .s ] something then ; If the stack comes back as anything other than empty then it's almost 100% sure that the thing you're seeing on the stack is an address or some other type of token that will be consumed by THEN. In other words, the data stack is being used as the control flow stack. The wording of the standard is clear here. The standard merely introduces the *concept* of a control flow stack, but it permits the data stack to be used instead. The wording of the standard is clear here, I don't see it as ambiguous or difficult to understand. In use, it can introduce some ambiguity, however, which means that one program may work on one system, and not on another, yet the program would be compliant with the standard. *These* are the issues that need to be addressed in the standard. These little gotchas. I'm actually quite a fan of the control stack. My system is contemporary, however - it uses the data stack during evaluation of IF...THEN. If I re-wrote my system, I'd probably leave that as it is, but I would implement a third stack for DO...LOOP which would have the advantage of leaving the return stack free for temporary use within a loop. Then again, might as well leave it as it is, and implement a temporary stack for temporary things: >t ( n -- t: -- n ) t> ( -- n t: n -- ) :-) Forth is *so* frickin' cool :-)
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-06-23 18:13 -0400 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <op.x0peo1aayfako5@localhost> |
| In reply to | #39985 |
On Tue, 23 Jun 2015 06:38:27 -0400, Mark Wills <markwills1970@gmail.com> wrote: > The point is simply that the token > should be the "atom" which can be "split" with other words to reveal > other information about the word. > > xt --> link field > xt --> flags > xt --> run-time semantics > xt --> interpretation semantics > xt --> compilation semantics > ... > Furthermore, a method is required to be able to associate the > three types of semantics with a single word. What three types of semantics? I.e., if an XT is just an address which is just an integer, it has no semantics whatsoever. E.g., ' (tick) and FIND return the CFA for my Forth which is also the XT. Which semantics is the CFA? I.e., isn't it all three? E.g., is this what you mean? interpretation: FIND used in inner interpreter and inner compiler ... run-time: ' <word> EXECUTE where ' uses FIND compilation: ' <word> COMPILE, where ' uses FIND How the XT is understood depends on how it is accessed or used, i.e., raw data read at the address, code executed from the CFA or XT, saved as an interpreter token, etc. BTW, I use ' <word> XDUMP in my forth. XDUMP is the longest high-level Forth word I've ever written. It displays all fields in the dictionary entry with nice labels, e.g., LFA, NFA, CFA, PFA etc, and with the data as 32-bit hex or strings. XDUMP is much nicer than just using DUMP . > And therein is the > problem: A *single* word has up to three different behaviours, > but the standard does not fully cover getting/setting and > compiling for those modes. > > How to fix it? > > I like: > > set-comp ( xt1 xt2 -- ) > The compilation semantics of the word identified by xt2 shall be > set to xt1. During compilation, FIND , tick, COMPILE, et al shall > return xt1. > > set-int ( xt1 xt2 -- ) > The interpretation semantics of the word identified by xt2 shall be > set to xt1. During interpretation, FIND , tick et al shall return > xt1. In general, this separation of semantics looks problematic to me. It seems to be an end-run around STATE aware words, which leads to implementation problems since it would seem to require duplicating certain aspects of the dictionary entry. In essence, doesn't it force you to implement two PFAs? I.e., one PFA area is needed for interpretation semantics and another PFA area is needed for compilation semantics, whereas a STATE aware word would have one definition with an IF ELSE THEN. Am I understanding this correctly? You're indicating possible multiple XTs, which could be done too. If a word has multiple XTs, e.g., one for interpretation and another for compilation, where are the PFA areas for all these XTs stored? Is this like a CREATEd word followed by a NONAME word, where the first word controls the PFA areas for both? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-24 01:44 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2738c663-13f1-4970-b39f-771b0d83644b@googlegroups.com> |
| In reply to | #40006 |
On Tuesday, 23 June 2015 23:13:28 UTC+1, Rod Pemberton wrote:
>
> What three types of semantics? I.e., if an XT is just an address
> which is just an integer, it has no semantics whatsoever.
* Interpretation semantics: What the interpreter should do when
it encounters a word;
* Compilation semantics: What the compiler should do when it
encounters a word;
* Execution semantics: What the word *itself* should do when it
is executed.
Or at least, that's how I resolve them in my head. [1]
Example:
: bar ( -- 1 2 3 ) 1 2 3 ;
: foo ( -- 1 2 3 )
state @ if
bar
else
true abort" Not in interpretation state, you don't!"
then ;
Looking at bar:
Execution semantics: push 1 2 & 3 to the stack
Interpretation semantics: same as execution semantics
Compilation semantics: None
Looking at foo:
Interpretation semantics: Issue an error and abort
Compilation semantics: Compile a reference to bar
Execution semantics: none - it never gets compiled into a
definition, unlike, say, drop or SWAP, unless you explicitly
compile it, and then you're in state-smart hell. If you do
compile it, you'll most likely get the interpretation
semantics, which is an abort, unless state is non-zero for
some reason. There's no way to explicitly get the compilation
semantics via ' or ['] or find, because they are embedded in
the state-smart code.
[1] IMO the Forth 200x standard is unhelpful in defining the
meaning of the semantics.
[quote] (Forth 200x 14.5)
3.4.3 Semantics
The semantics of a Forth definition are implemented by machine
code or a sequence of execution tokens or other representations.
They are largely specified by the stack notation in the glossary
entries, which shows what values shall be consumed and produced.
The prose in each glossary entry further specifies the definition's
behavior.
Each Forth definition may have several behaviors, described in the
following sections. The terms "initiation semantics" and "run-time
semantics" refer to definition fragments, and have meaning only
within the individual glossary entries where they appear.
3.4.3.1 Execution semantics
The execution semantics of each Forth definition are specified in an "Execution:" section of its glossary entry. When a definition
has only one specified behavior, the label is omitted.
Execution may occur implicitly, when the definition into which it
has been compiled is executed, or explicitly, when its execution
token is passed to EXECUTE. The execution semantics of a syntactically
correct definition under conditions other than those specified in
this standard are implementation dependent.
Glossary entries for defining words include the execution semantics
for the new definition in a "name Execution:" section.
3.4.3.2 Interpretation semantics
Unless otherwise specified in an "Interpretation:" section of the
glossary entry, the interpretation semantics of a Forth definition
are its execution semantics.
A system shall be capable of executing, in interpretation state,
all of the definitions from the Core word set and any definitions
included from the optional word sets or word set extensions whose
interpretation semantics are defined by this standard.
A system shall be capable of executing, in interpretation state,
any new definitions created in accordance with 3 Usage requirements.
3.4.3.3 Compilation semantics
Unless otherwise specified in a "Compilation:" section of the
glossary entry, the compilation semantics of a Forth definition
shall be to append its execution semantics to the execution
semantics of the current definition.
[/quote]
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-06-24 20:07 -0400 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <op.x0rel3s2yfako5@localhost> |
| In reply to | #40011 |
On Wed, 24 Jun 2015 04:44:42 -0400, Mark Wills <markwills1970@gmail.com> wrote: > On Tuesday, 23 June 2015 23:13:28 UTC+1, Rod Pemberton wrote: >> What three types of semantics? I.e., if an XT is just an address >> which is just an integer, it has no semantics whatsoever. > > * Interpretation semantics: What the interpreter should do when > it encounters a word; > * Compilation semantics: What the compiler should do when it > encounters a word; > * Execution semantics: What the word *itself* should do when it > is executed. > > Or at least, that's how I resolve them in my head. [1] > > Example: > > : bar ( -- 1 2 3 ) 1 2 3 ; > : foo ( -- 1 2 3 ) > state @ if > bar > else > true abort" Not in interpretation state, you don't!" > then ; > > Looking at bar: > Execution semantics: push 1 2 & 3 to the stack > Interpretation semantics: same as execution semantics > Compilation semantics: None > > > Looking at foo: > Interpretation semantics: Issue an error and abort > Compilation semantics: Compile a reference to bar > Execution semantics: none - it never gets compiled into a > definition, unlike, say, drop or SWAP, unless you explicitly > compile it, and then you're in state-smart hell. If you do > compile it, you'll most likely get the interpretation > semantics, which is an abort, unless state is non-zero for > some reason. There's no way to explicitly get the compilation > semantics via ' or ['] or find, because they are embedded in > the state-smart code. > > [1] IMO the Forth 200x standard is unhelpful in defining the > meaning of the semantics. > The compilation semantics of foo are automatically available in compilation mode, via STATE where implemented, or from interpreted mode via ] (rbrac). So, why would you need the compilation semantics of foo if not in compilation mode? ... Where would you use this? I.e., the delineation of these modes as implemented for classic Forth interpreters seems to be adequate. It's entirely possible I might've used something like that somewhere but didn't grasp this aspect of it, e.g., COMPILE or [COMPILE] or POSTPONE etc. Rod Pemberton -- It's time to put an end to gun violence! Use a hammer ...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-25 17:05 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun25.190517@mips.complang.tuwien.ac.at> |
| In reply to | #40040 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>The compilation semantics of foo are automatically available in
>compilation mode, via STATE where implemented, or from interpreted
>mode via ] (rbrac). So, why would you need the compilation
>semantics of foo if not in compilation mode?
An example is a code generator with parameters:
: foo [ 5 gen-some-code 6 gen-more-code ] ;
where GEN-SOME-CODE contains POSTPONE <x> among other things, i.e.,
the compilation semantics of <x>.
- 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-24 02:08 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <f0efa226-3694-4055-89dd-28703d036cf4@googlegroups.com> |
| In reply to | #40006 |
On Tuesday, 23 June 2015 23:13:28 UTC+1, Rod Pemberton wrote: > In general, this separation of semantics looks problematic to me. > It seems to be an end-run around STATE aware words, which leads to > implementation problems since it would seem to require duplicating > certain aspects of the dictionary entry. > Yes. > In essence, doesn't it force you to implement two PFAs? I.e., > one PFA area is needed for interpretation semantics and another > PFA area is needed for compilation semantics, If you want to access them individually (to compile them or to execute them, then yes). But the standard provides no means (at the moment) to do that. > whereas a STATE > aware word would have one definition with an IF ELSE THEN. Am > I understanding this correctly? Yep. You got it. > You're indicating possible > multiple XTs, which could be done too. Yes. That's what I'm advocating. But those XTs would actually be the XTs of other words defined in the dictionary. By doing this: * Factoring of different semantics into different words is enforced; * Each word has exactly one XT and one XT only. Simple. Here's an example: S" Interpretation behaviour of S": copy a quote delimited string to a temporary, transient area of memory. Push the address of the string in the temporary area to the stack. Push the length of the string in the temporary area to the stack. Compilation behaviour of S": Copy a quote delimited string into the current definition, such that, at run-time (when the word under definition is executed) the address of the string and the length of the string is pushed to the stack. Execution behaviour of S": Push the address of the compiled string, and the length of the compiled string to the stack. How do we uniquely access (or set) those behaviours, when a word has only one name, and one XT? My idea: : S"-comp \ compilation semantics of S" ; : s"-exec \ execution semantics of S" ; : S" \ interpretation semantics of S" ; immediate Each of the "modes" of the word is in its own definition. Each definition has exactly one name, and one XT. Now, we need to associate the execution and compilation semantics of with S": ' s"-comp ' S" set-comp \ set s" compilation semantics ' s"-exec ' s" set-int \ set s" interpretation semantics You can see that this would require fields in the header of S" in order to accomodate the XTs of the interpretation and comp. semantics. This would be wasteful to do for every word (most words don't have special semantics) so a method would need to be devised to accomodate these. I have some ideas on how to do this, but it's essentially an implementation detail. Now, if we want to get the compilation semantics of S" , how would we do that? My suggestion: via the XT of S" and convert it into another XT via a helper word: ' s" >comp Now we have the compilation XT of S" - which is the exact same XT as s"-comp. You can see that >comp is a simple look-up into the header of s". Very simple. FIND et al still work. COMPILE, et al would still work. Each word still has one name. Each word still has one XT. If a word has multiple > XTs, e.g., one for interpretation and another for compilation, > where are the PFA areas for all these XTs stored? See above. HTH Mark
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-24 04:53 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <c978c79e-5294-4ca4-9493-59544794ecf2@googlegroups.com> |
| In reply to | #40012 |
miercuri, 24 iunie 2015, 12:08:08 UTC+3, Mark Wills a scris: > On Tuesday, 23 June 2015 23:13:28 UTC+1, Rod Pemberton wrote: > > In general, this separation of semantics looks problematic to me. > > It seems to be an end-run around STATE aware words, which leads to > > implementation problems since it would seem to require duplicating > > certain aspects of the dictionary entry. > > > Yes. > > > In essence, doesn't it force you to implement two PFAs? I.e., > > one PFA area is needed for interpretation semantics and another > > PFA area is needed for compilation semantics, > > If you want to access them individually (to compile them or to > execute them, then yes). But the standard provides no means (at > the moment) to do that. > > > whereas a STATE > > aware word would have one definition with an IF ELSE THEN. Am > > I understanding this correctly? > > Yep. You got it. > > > You're indicating possible > > multiple XTs, which could be done too. > > Yes. That's what I'm advocating. But those XTs would actually > be the XTs of other words defined in the dictionary. By doing > this: > > * Factoring of different semantics into different words is > enforced; > * Each word has exactly one XT and one XT only. > > Simple. > > Here's an example: S" > > Interpretation behaviour of S": copy a quote delimited string > to a temporary, transient area of memory. Push the address of > the string in the temporary area to the stack. Push the length > of the string in the temporary area to the stack. > > Compilation behaviour of S": Copy a quote delimited string into > the current definition, such that, at run-time (when the word > under definition is executed) the address of the string and > the length of the string is pushed to the stack. > > Execution behaviour of S": Push the address of the compiled > string, and the length of the compiled string to the stack. > > How do we uniquely access (or set) those behaviours, when a > word has only one name, and one XT? > > My idea: > > > > : S"-comp > \ compilation semantics of S" > ; > > : s"-exec > \ execution semantics of S" > ; > > : S" > \ interpretation semantics of S" > ; immediate > > Each of the "modes" of the word is in its own definition. Each definition > has exactly one name, and one XT. > > Now, we need to associate the execution and compilation semantics of > with S": > > ' s"-comp ' S" set-comp \ set s" compilation semantics > ' s"-exec ' s" set-int \ set s" interpretation semantics > > You can see that this would require fields in the header of S" > in order to accomodate the XTs of the interpretation and comp. > semantics. This would be wasteful to do for every word (most > words don't have special semantics) so a method would need to > be devised to accomodate these. I have some ideas on how to do > this, but it's essentially an implementation detail. > > Now, if we want to get the compilation semantics of S" , how > would we do that? My suggestion: via the XT of S" and convert > it into another XT via a helper word: > > ' s" >comp > > Now we have the compilation XT of S" - which is the exact same > XT as s"-comp. You can see that >comp is a simple look-up into > the header of s". > > Very simple. FIND et al still work. COMPILE, et al would still > work. Each word still has one name. Each word still has one XT. > > If a word has multiple > > XTs, e.g., one for interpretation and another for compilation, > > where are the PFA areas for all these XTs stored? > > See above. > > HTH > > Mark I really don't understand why do you think that S" is so complicated. In my system S" is a primitive, state smart and immediate. Simple. It is only one word, one XT. Tick returns the XT and the XT works in both interpretation and compilation. In the REPL I even can do this: s" hello" type hello ok ' s" execute hello" type hello ok idef ." ' s" compile, ' type eval_xt ; ok ." hi" hi ok Notes: idef defines an immediate word (like : <name> ... ; immediate ) directly. eval_xt compiles or executes the xt based on state (probably like postpone). ' (tick) is state smart too, I don't have different ' and ['] Simple.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-24 04:57 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <0f8512bc-79cf-4861-ac41-b189a0066d5a@googlegroups.com> |
| In reply to | #40013 |
miercuri, 24 iunie 2015, 14:53:33 UTC+3, Raimond Dragomir a scris: > miercuri, 24 iunie 2015, 12:08:08 UTC+3, Mark Wills a scris: > > On Tuesday, 23 June 2015 23:13:28 UTC+1, Rod Pemberton wrote: > > > In general, this separation of semantics looks problematic to me. > > > It seems to be an end-run around STATE aware words, which leads to > > > implementation problems since it would seem to require duplicating > > > certain aspects of the dictionary entry. > > > > > Yes. > > > > > In essence, doesn't it force you to implement two PFAs? I.e., > > > one PFA area is needed for interpretation semantics and another > > > PFA area is needed for compilation semantics, > > > > If you want to access them individually (to compile them or to > > execute them, then yes). But the standard provides no means (at > > the moment) to do that. > > > > > whereas a STATE > > > aware word would have one definition with an IF ELSE THEN. Am > > > I understanding this correctly? > > > > Yep. You got it. > > > > > You're indicating possible > > > multiple XTs, which could be done too. > > > > Yes. That's what I'm advocating. But those XTs would actually > > be the XTs of other words defined in the dictionary. By doing > > this: > > > > * Factoring of different semantics into different words is > > enforced; > > * Each word has exactly one XT and one XT only. > > > > Simple. > > > > Here's an example: S" > > > > Interpretation behaviour of S": copy a quote delimited string > > to a temporary, transient area of memory. Push the address of > > the string in the temporary area to the stack. Push the length > > of the string in the temporary area to the stack. > > > > Compilation behaviour of S": Copy a quote delimited string into > > the current definition, such that, at run-time (when the word > > under definition is executed) the address of the string and > > the length of the string is pushed to the stack. > > > > Execution behaviour of S": Push the address of the compiled > > string, and the length of the compiled string to the stack. > > > > How do we uniquely access (or set) those behaviours, when a > > word has only one name, and one XT? > > > > My idea: > > > > > > > > : S"-comp > > \ compilation semantics of S" > > ; > > > > : s"-exec > > \ execution semantics of S" > > ; > > > > : S" > > \ interpretation semantics of S" > > ; immediate > > > > Each of the "modes" of the word is in its own definition. Each definition > > has exactly one name, and one XT. > > > > Now, we need to associate the execution and compilation semantics of > > with S": > > > > ' s"-comp ' S" set-comp \ set s" compilation semantics > > ' s"-exec ' s" set-int \ set s" interpretation semantics > > > > You can see that this would require fields in the header of S" > > in order to accomodate the XTs of the interpretation and comp. > > semantics. This would be wasteful to do for every word (most > > words don't have special semantics) so a method would need to > > be devised to accomodate these. I have some ideas on how to do > > this, but it's essentially an implementation detail. > > > > Now, if we want to get the compilation semantics of S" , how > > would we do that? My suggestion: via the XT of S" and convert > > it into another XT via a helper word: > > > > ' s" >comp > > > > Now we have the compilation XT of S" - which is the exact same > > XT as s"-comp. You can see that >comp is a simple look-up into > > the header of s". > > > > Very simple. FIND et al still work. COMPILE, et al would still > > work. Each word still has one name. Each word still has one XT. > > > > If a word has multiple > > > XTs, e.g., one for interpretation and another for compilation, > > > where are the PFA areas for all these XTs stored? > > > > See above. > > > > HTH > > > > Mark > > I really don't understand why do you think that S" is so complicated. > In my system S" is a primitive, state smart and immediate. Simple. It is > only one word, one XT. Tick returns the XT and the XT works in both > interpretation and compilation. > In the REPL I even can do this: > > s" hello" type > hello ok > ' s" execute hello" type > hello ok > idef ." ' s" compile, ' type eval_xt ; > ok > ." hi" > hi ok > > Notes: > idef defines an immediate word (like : <name> ... ; immediate ) directly. > eval_xt compiles or executes the xt based on state (probably like postpone). > ' (tick) is state smart too, I don't have different ' and ['] > > Simple. Ok, I missed another test case. Here it is: def foo s" xxx" type ; foo reDef ok foo xxx ok
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-24 05:46 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <f26a289d-17e3-40b4-8725-4c406b6247de@googlegroups.com> |
| In reply to | #40013 |
On Wednesday, 24 June 2015 12:53:33 UTC+1, Raimond Dragomir wrote: > > I really don't understand why do you think that S" is so complicated. > In my system S" is a primitive, state smart and immediate. Simple. It is > only one word, one XT. Tick returns the XT and the XT works in both > interpretation and compilation. > In the REPL I even can do this: > > s" hello" type > hello ok > ' s" execute hello" type > hello ok > idef ." ' s" compile, ' type eval_xt ; > ok > ." hi" > hi ok > > Notes: > idef defines an immediate word (like : <name> ... ; immediate ) directly. > eval_xt compiles or executes the xt based on state (probably like postpone). > ' (tick) is state smart too, I don't have different ' and ['] > > Simple. Hi Raimond, My 16-bit ITC hobby system (written by me) behaves the same as yours! I can do: ' s" execute hello world" cr type and it works just fine. It's *only* a problem when you want to get at the *specific behaviours* of the word. In the case of S" there are three behaviours of s" and they are all different: S" does a particular thing in immediate mode (state=0) it does something different in compilation mode it does something different when executed in a compiled definition. From my earlier post to Rod: Interpretation behaviour of S": copy a quote delimited string to a temporary, transient area of memory. Push the address of the string in the temporary area to the stack. Push the length of the string in the temporary area to the stack. Compilation behaviour of S": Copy a quote delimited string into the current definition, such that, at run-time (when the word under definition is executed) the address of the string and the length of the string is pushed to the stack. Execution behaviour of S": Push the address of the compiled string, and the length of the compiled string to the stack. In a typical state-smart word, ticking and compiling the word will lead to the interpretation semantics being executed when that word is eventually executed. However, that might not be the behaviour that you want. And there be the crux of the problem. Mark
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-24 07:05 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <6b6d6db2-d73e-4a5d-9936-6f8ebfae9004@googlegroups.com> |
| In reply to | #40015 |
> > In a typical state-smart word, ticking and compiling the word > will lead to the interpretation semantics being executed > when that word is eventually executed. However, that might > not be the behaviour that you want. And there be the crux of > the problem. > > Mark I understand very well the crux of the problem, what I don't understand is why should it be so complicated. Because it's not. Yes, there are two different execution semantics for S". When you execute it in interpretation mode, it delivers the adr len of some buffer. When you execute what you compiled, it delivers the adr len of the compiled copy in the code. Yes, there are two words if you want, but they are dispatched by state, in a single state smart word. What's so complicated? Is the state smartness the problem? In my view, state smartness is quite simple. My system is a very simple one, with state smart words and immediate flags. If you understand what is all about, you can do whatever you want. For a S" type of a word, you should recognize the fact that you need two "words", the rest is trivial. I don't think it's a language deficiency. Not easy? Yes, not very easy for a regular application programmer, more for a system programmer. Maybe S" given as an example here is too simple, maybe there are cases more complicated. But I don't see how another sofistication with multiple XTs could simplify a system based on state smart words and immediacy.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-24 14:40 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <558ac0e6.517384835@news.eternal-september.org> |
| In reply to | #40020 |
On Wed, 24 Jun 2015 07:05:41 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >Maybe S" given as an example here is too simple, maybe there are cases >more complicated. But I don't see how another sofistication with multiple >XTs could simplify a system based on state smart words and immediacy. Thank you for that. It's an excellent reminder that state-smartness still has a place in the Forth world. Forth has always been a dangerous language. It should remain so. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-24 10:12 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <d81cee61-70ce-4bd4-857f-4e1552f3df95@googlegroups.com> |
| In reply to | #40024 |
miercuri, 24 iunie 2015, 17:40:30 UTC+3, Stephen Pelc a scris: > On Wed, 24 Jun 2015 07:05:41 -0700 (PDT), Raimond Dragomir > <raimond.dragomir@gmail.com> wrote: > > >Maybe S" given as an example here is too simple, maybe there are cases > >more complicated. But I don't see how another sofistication with multiple > >XTs could simplify a system based on state smart words and immediacy. > > Thank you for that. It's an excellent reminder that state-smartness > still has a place in the Forth world. Forth has always been a > dangerous language. It should remain so. > > Stephen > > -- > Stephen Pelc, stephenXXX@mpeforth.com > MicroProcessor Engineering Ltd - More Real, Less Time > 133 Hill Lane, Southampton SO15 5AF, England > tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 > web: http://www.mpeforth.com - free VFX Forth downloads You probably are sarcastic. I admit that in my (simple) system I have to check manually if the word is immediate or not if I want to compile it. My LOCATE is telling me the immediacy along with other info. I don't have a magic POSTPONE. But I'm pretty sure I don't want one because it seems that it's magic is broken in many situation. I've read the Anton's paper :) What I know is that my (simple) system works where other systems don't (from what I've read in that paper). That's enough for me.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-24 20:35 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <558b142b.538701934@news.eternal-september.org> |
| In reply to | #40031 |
On Wed, 24 Jun 2015 10:12:30 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >You probably are sarcastic. No. I was not being sarcastic. There are plenty of people who do not post on c.l.f who believe that state-smart words are useful, even after recognising that they can be dangerous if misused. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-24 15:01 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun24.170123@mips.complang.tuwien.ac.at> |
| In reply to | #40020 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>Is the state smartness
>the problem?
Yes.
@InProceedings{ertl98,
author = {M. Anton Ertl},
title = {\texttt{State}-smartness --- Why it is Evil and How
to Exorcise it},
booktitle = {EuroForth'98 Conference Proceedings},
year = {1998},
address = {Schlo\ss{} Dagstuhl},
url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
abstract = {\texttt{State}-smart words provide a number of unpleasant
surprises to their users. They are applied in two
contexts, and they fail in both: 1) for providing an
arbitrary combination of interpretation and
compilation semantics; 2) for optimizing with a
special implementation of the (default) compilation
semantics. This paper discusses these issues and
shows programmers and system implementors how to
avoid \texttt{state}-smart words. It also reports our
experiences in converting the \texttt{state}-smart
words in Gforth into a clean solution: little work
and few problems.}
}
- 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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-24 08:58 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <0bb265fc-0efd-491b-accd-e1846c9b3566@googlegroups.com> |
| In reply to | #40026 |
miercuri, 24 iunie 2015, 18:03:26 UTC+3, Anton Ertl a scris:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> >Is the state smartness
> >the problem?
>
> Yes.
>
> @InProceedings{ertl98,
> author = {M. Anton Ertl},
> title = {\texttt{State}-smartness --- Why it is Evil and How
> to Exorcise it},
> booktitle = {EuroForth'98 Conference Proceedings},
> year = {1998},
> address = {Schlo\ss{} Dagstuhl},
> url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
> abstract = {\texttt{State}-smart words provide a number of unpleasant
> surprises to their users. They are applied in two
> contexts, and they fail in both: 1) for providing an
> arbitrary combination of interpretation and
> compilation semantics; 2) for optimizing with a
> special implementation of the (default) compilation
> semantics. This paper discusses these issues and
> shows programmers and system implementors how to
> avoid \texttt{state}-smart words. It also reports our
> experiences in converting the \texttt{state}-smart
> words in Gforth into a clean solution: little work
> and few problems.}
> }
>
> - 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
Can you provide a pdf, doc or txt? I cannot read .ps files in my windows box.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-24 09:54 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <ecea16d7-958d-4d93-84ae-3da8f4565b46@googlegroups.com> |
| In reply to | #40029 |
miercuri, 24 iunie 2015, 18:58:03 UTC+3, Raimond Dragomir a scris:
> miercuri, 24 iunie 2015, 18:03:26 UTC+3, Anton Ertl a scris:
> > Raimond Dragomir <raimond.dragomir@gmail.com> writes:
> > >Is the state smartness
> > >the problem?
> >
> > Yes.
> >
> > @InProceedings{ertl98,
> > author = {M. Anton Ertl},
> > title = {\texttt{State}-smartness --- Why it is Evil and How
> > to Exorcise it},
> > booktitle = {EuroForth'98 Conference Proceedings},
> > year = {1998},
> > address = {Schlo\ss{} Dagstuhl},
> > url = {http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz},
> > abstract = {\texttt{State}-smart words provide a number of unpleasant
> > surprises to their users. They are applied in two
> > contexts, and they fail in both: 1) for providing an
> > arbitrary combination of interpretation and
> > compilation semantics; 2) for optimizing with a
> > special implementation of the (default) compilation
> > semantics. This paper discusses these issues and
> > shows programmers and system implementors how to
> > avoid \texttt{state}-smart words. It also reports our
> > experiences in converting the \texttt{state}-smart
> > words in Gforth into a clean solution: little work
> > and few problems.}
> > }
> >
> > - 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
>
> Can you provide a pdf, doc or txt? I cannot read .ps files in my windows box.
Never mind, I found a pdf on the net.
I will not argue with you because my system is not standard. I assume what
you wrote there is correct for a standard forth. But what you have written
is so terrible wrong on my system (where everything seems to work very well)
that I must assume that my system is non standard and that's it - and I'm
so glad it is... because it's so simple!
For example, on your 2dup example, every case there works on my system. I just
tested a lot of combinations. But my system - I admit - has some differences:
1. I don't have POSTPONE
2. I don't have [COMPILE]
3. I don't have [ and ] - there is no way in my system to turn on and off
the state just like that. It's really ugly and I'm pretty sure this confuses
a lot of programmers. Me for sure.
4. I'm also not very sure if my COMPILE and COMPILE, are exactly the same
as the standard ones.
What I have:
COMPILE
which parses the next word and compiles it. It is for compiling
immediate words. Normal words are compiled directly, and we need a way to
compile immediate words too (otherwise they get executed not compiled)
COMPILE,
which is a normal word. It expects an xt on the stack, and compiles it
but when the word where it is compiled is executed. With COMPILE, we can
write words that are able to compile something on their turn.
EVAL_XT
This word, and an entire familiy of words like it with constant folding
functionality, is a state smart word. It does COMPILE, in compiling mode
and EXECUTE in interpretation mode.
That's it. Also, my outer interpreter is a bit different. I have another
flag in the dictionary indicating if the word is "data" or "code". Only
if the word is "code" the outer interpreter behaves differently based on
state (compilation/execution). If the word is "data" it leaves it's address
on the stack in BOTH modes. Also, if the word is a number, it also leaves
the value on the stack in BOTH modes (stadard systems must compile a LITERAL
in compilation mode). With this, the constant folding optimization is
so natural, and the whole outer interpreter is in fact simpler.
But I don't know if this has some relation with the problem of the state-smartness.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-28 16:40 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun28.184044@mips.complang.tuwien.ac.at> |
| In reply to | #40030 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>What I have:
>COMPILE
> which parses the next word and compiles it. It is for compiling
>immediate words. Normal words are compiled directly, and we need a way to
>compile immediate words too (otherwise they get executed not compiled)
That is [COMPILE], and, when used for immediate words, POSTPONE.
- 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 | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-06-28 15:10 -0400 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <op.x0yfjr0yyfako5@localhost> |
| In reply to | #40030 |
On Wed, 24 Jun 2015 12:54:07 -0400, Raimond Dragomir <raimond.dragomir@gmail.com> wrote: > I just tested a lot of combinations. But my system - I admit - has some > differences: > 1. I don't have POSTPONE > 2. I don't have [COMPILE] > 3. I don't have [ and ] - there is no way in my system to turn on and off > the state just like that. It's really ugly and I'm pretty sure this > confuses > a lot of programmers. Me for sure. > 4. I'm also not very sure if my COMPILE and COMPILE, are exactly the same > as the standard ones. > > What I have: > COMPILE > which parses the next word and compiles it. It is for compiling > immediate words. Normal words are compiled directly, and we need a way to > compile immediate words too (otherwise they get executed not compiled) > > COMPILE, > which is a normal word. It expects an xt on the stack, and compiles it > but when the word where it is compiled is executed. With COMPILE, we can > write words that are able to compile something on their turn. > > EVAL_XT > This word, and an entire familiy of words like it with constant folding > functionality, is a state smart word. It does COMPILE, in compiling mode > and EXECUTE in interpretation mode. > If you have a threaded, interpreted Forth, then COMPILE, is just , (comma). : COMPILE, , ; : [COMPILE] ' , ; immediate POSTPONE is usually built with COMPILE and COMPILE, or , (comma) with the beginning similar to ' (tick). See this post of mine from a few years ago where I repeat a bunch of the c.l.f. definitions for POSTPONE over the years. You may need to scroll down a bit: https://groups.google.com/forum/#!msg/comp.lang.forth/RqN6h4qNlPs/RrktBeS62cUJ So, now, you should just be missing [ and ] hopefully. Rod Pemberton -- Tolerance and socialism attracts intolerance and terrorism. See: France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
[toc] | [prev] | [next] | [standalone]
Page 16 of 26 — ← Prev page 1 … 14 15 [16] 17 18 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web