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 11 of 26 — ← Prev page 1 … 9 10 [11] 12 13 … 26 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-29 03:09 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmq5qd$8u7$1@dont-email.me> |
| In reply to | #40103 |
Anton Ertl wrote: >>That's Forth: you can't enforce rules, but you strive for simplicity. > > Yes. And having two classes of xts is not simplicity. Right now, regarding compilation semantics, we have two classes of xts: One class compiles with COMPILE, and the other class compiles with EXECUTE (immediate words). Regarding interpretation semantics, we have again two classes, too: One class performs interpretation semantics with ' foo EXECUTE. The other has no interpretation semantics, so it either can't be ticked, or ' foo EXECUTE does something else than the interpretation semantics (the compilation semantics). All four combinations exist in the standard, so in the end, we now have four classes of xts, regarding the relation between execution semantic of the xt and the interpretation and compilation semantics of the words behind. There's probably one class or xt regarding COMPILE,, but since some xts aren't tickable, and EXECUTE is meaningless (despite some of them actually are specified as "execution semantics"), I doubt this is actually true. Reducing those four classes to two is a considerable simplification. It comes at the cost that the two classes are now exposed at a different place - COMPILE, now behaves different on words with default compilation semantics as with non-default compilation semantics. Note that this difference (default or non-default compilatin semantics) always existed, so it's not a new division into two classes. The dual-xt approach adds a new type (nt), and converts that type into a total of three xts (either one for interpretation or two for compilation), doesn't look conceptionally simpler to me. > Increasing the complexity of the interface for a little simpliciation > in implementation is not a simplification. I'm looking at the bigger picture. There's more to this than just COMPILE,. Simplification is always a tradeoff. > If you really want to simplify, get rid of S" and friends, and make > all words either normal or immediate, and then all the internal stuff > we are discussion can be much simpler, and we have a simpler > interface. Well, with just normal or immediate, the optimizer problem can't be solved. That's what RFI 7 was about, the answer was a slap into immediate+state's face. We can get rid of optimizers for the sake of simplicity, too... do we want to? Maybe not. > In this case, if we consider where Forth-94 is a flawed specification, > it seems to me that the specification error is that Forth-94 included > S" and friends, and that it made words without interpretation > semantics. Lots of complexity in implementation and interfaces fell > out from that. The compile-only words came from Forth-83, so at least it wasn't something new. Forth-94 just tried a "neutral" formulation. http://forth.sourceforge.net/standard/fst83/fst83-11.htm >>Words like S" are originally meant for the text interpreter only - and >>they work well there, regardless if you implement them STATE-smart, >>dual-xt or >>smart COMPILE,. They are not meant to be used as factors. > > Ok, that's a less radical simplification. But then we don't need to > tick and POSTPONE S"; we should just specify that, and also revise > FIND so that it is usable in text interpreters (and not make > guarantees beyond that). With recognizers, REC:WORD would be that replacement for FIND. That's doing whatever things need to be done for a text interpreter. It is specified in a STATE-agnostic way, so whatever your internals are, REC:WORD's stack effect is ( addr u -- x r:something | r:fail ), and x+r:something can be used to get interpretation, compilation and postpone semantics. I'm not sure if there needs to be a SEARCH-WORDLIST equivalent, as GET-ORDER N>R wid 1 SET-ORDER REC:WORD NR> SET-ORDER would do that job. This FIND replacement however can't be used to implement your own versions of ' or so (which you sometimes actually want). Usually, the reason why people write their own text interpreter is that they either want to add to or subtract from the current text interpreter. This is much easier with a recognizer stack. You now have reusable and configurable components that can be made to do what you want. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-06-27 06:42 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <54465c94-4c55-448a-9763-bc5dda5f93ba@googlegroups.com> |
| In reply to | #40084 |
On Saturday, June 27, 2015 at 12:00:10 PM UTC+2, Alex McDonald wrote: > on 27/06/2015 00:09:38, Bernd Paysan wrote: [..] > Thanks for the history. The TAOCP is a fine, seminal and important work, > but Knuth's MIX wasn't his finest hour. Sainthood especially needs tested > in the fire of facts. MIX works fine. There is a (64-bit) Forth emulator + register level debugger for it that can run non-trivial programs. I guess MIX was designed to be similar to all machines of that era, not to improve on them (cf. MMIX). -marcel
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-28 13:21 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmooq5$oah$1@dont-email.me> |
| In reply to | #40087 |
on 27/06/2015 14:42:25, wrote: > On Saturday, June 27, 2015 at 12:00:10 PM UTC+2, Alex McDonald wrote: >> on 27/06/2015 00:09:38, Bernd Paysan wrote: > [..] >> Thanks for the history. The TAOCP is a fine, seminal and important work, >> but Knuth's MIX wasn't his finest hour. Sainthood especially needs tested >> in the fire of facts. > > MIX works fine. There is a (64-bit) Forth emulator + register level > debugger for it that can run non-trivial programs. > > I guess MIX was designed to be similar to all machines > of that era, not to improve on them (cf. MMIX). > > -marcel > > http://xkcd.com/163/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-26 12:20 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmjcf0$3s6$1@dont-email.me> |
| In reply to | #40057 |
on 25/06/2015 21:45:04, wrote: > > Charles Moore came up with the idea that there would not be a > monolithic co mpiler (such as in Pascal) that knows how to compile the > language, but that each immediate word would know how to compile > itself. You have betrayed th is idea by making COMPILE, the monolithic > compiler that special-cases dozen s of words in the language. Words > like IF don't know how to compile themsel ves, because they aren't > immediate --- they are special-cased by COMPILE, t hat compiles them > in a special-case way different from how it compiles othe r > non-immediate words --- you are failing to remember that in Forth the > onl y attribute a word can have is immediate or non-immediate, and you > have for ced your users to know a-priori that dozens of words are > special-case. As did [COMPILE]. Every word had to declare its immediacy. ANS removed that requirement with POSTPONE. Also note that STATE is an attribute too.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-12 19:43 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <8d8b32c3-da26-4df1-91d4-15298cc930c5@googlegroups.com> |
| In reply to | #40057 |
On Thursday, June 25, 2015 at 1:45:08 PM UTC-7, hughag...@gmail.com wrote: > On Thursday, June 25, 2015 at 9:33:51 AM UTC-7, Stephen Pelc wrote: > > On Thu, 25 Jun 2015 08:13:18 -0700 (PDT), Raimond Dragomir > > <raimond.dragomir@gmail.com> wrote: > > > > >I wonder, do we need this complexity? I suppose VFX need it in order > > >to achieve good code optimization. I don't know if gforth needs it for > > >the same reason. Probably a code generation comparable to C compilers > > >need this complexity. > > > > The VFX code generator is certainly complex. It's all hidden inside > > COMPILE, which is used inside a classical Fig-Forth style interpreter > > loop. Each word "knows" how to compile itself. > > > > Stephen > > The complexity is not very well hidden in VFX. You have xt values that can't be executed --- they are non-executable execution tokens (?!) --- this was the bug in IF that I described at the beginning of the thread. > > The VFX code generator continues to work after my disambiguifiers have been put in place --- but the bug in IF that I described at the beginning of this lengthy thread gets fixed. > > Charles Moore came up with the idea that there would not be a monolithic compiler (such as in Pascal) that knows how to compile the language, but that each immediate word would know how to compile itself. You have betrayed this idea by making COMPILE, the monolithic compiler that special-cases dozens of words in the language. Words like IF don't know how to compile themselves, because they aren't immediate --- they are special-cased by COMPILE, that compiles them in a special-case way different from how it compiles other non-immediate words --- you are failing to remember that in Forth the only attribute a word can have is immediate or non-immediate, and you have forced your users to know a-priori that dozens of words are special-case. > > The whole idea of IF etc. being non-immediate is a very screwball implementation --- my disambiguifiers hide the screwiness however by making IF etc. immediate and giving these words an xt value that can be executed --- we no longer have non-executable execution tokens. See Figure-4.7 in "Thinking Forth" --- which kind of compiler is VFX?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-28 14:09 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun28.160939@mips.complang.tuwien.ac.at> |
| In reply to | #40053 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>joi, 25 iunie 2015, 16:29:10 UTC+3, Mark Wills a scris:
>On the other hand, I've read the paper yesterday. It strikes me the fact
>that my system works where Anton claims it shouldn't work.
You don't provide your system, and you don't specify what claim is
supposedly wrong. Also, from what I saw in an earlier posting, you
translate between standard Forth and your system. It's easily
possible to lose something in the translation.
> IMO the paper
>is too loaded with "this will not work", "that is wrong", etc. A simple
>system like mine seems to work perfectly.
Sure, fans of STATE-smart systems claim that. My experience is that
they just don't use the system in a way that uncovers the pitfalls.
That does not guarantee that nobody else will.
>Maybe systems like gforth or VFX will not work. But systems like these
>are not simple. They cannot be simple when the IF is not immediate !
>How can a system have an non-immediate IF? It's clear that IF and
>others are special cased by the outer interpreter. So, a new level
>of complexity is added, we have non-immediate words, immediate words
>and (at least) one third category of words. For such a system Anton's
>paper may be true.
The things that VFX does have little to do with it (except that they
are another botched attempt to solve the same problems).
>I wonder, do we need this complexity? I suppose VFX need it in order
>to achieve good code optimization.
No. Add
: if postpone if ; immediate
to VFX, and IF in VFX will behave exactly as you expect, and it will
optimize just as well. I think that VFX defines IF the way it does
just because it can, not because it is a good idea.
> I don't know if gforth needs it for
>the same reason. Probably a code generation comparable to C compilers
>need this complexity.
In Gforth IF is compile-only in order to detect errors. You can make
it behave as you expect in the same way. Code generation has nothing
to do with it; you can leave the "compile-only" away, recompile, and
IF will behave just as if you redefined it as above.
- 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-28 10:21 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <aa2df9a3-c530-4639-a8db-e224a756ae35@googlegroups.com> |
| In reply to | #40104 |
> You don't provide your system, and you don't specify what claim is
> supposedly wrong. Also, from what I saw in an earlier posting, you
> translate between standard Forth and your system. It's easily
> possible to lose something in the translation.
Basically the
"2 Example: Optimization"
all the points there work for me now that you
said that my COMPILE is [COMPILE] or postpone...
At "2.5 Transformation using immediate" you give an example of S" which you
said "... but it fails with ', postpone etc..."
My S" is exactly like that. And it doesn't fail with tick, (my) COMPILE
COMPILE, etc.
In fact my ." word is defined as:
def compiling? \ -- flag
state @ 0> ;
def eval_xt \ xt --
compiling? if compile, else execute then ;
idef ."
compile s"
' type eval_xt ;
I tested S" and ." in a lot of combinations with no failure in either
interpreter or compiler. I compiled both in normal or immediate definitions
to three levels...
Anyway, I don't have POSTPONE, and I don't have the [ ] thing, so a lot
of discussion in the paper is not applicable to me... The users of my
systems cannot mess with [ ] things therefore (just an example).
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-28 14:26 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun28.162625@mips.complang.tuwien.ac.at> |
| In reply to | #40044 |
hughaguilar96@gmail.com writes:
>On Tuesday, June 23, 2015 at 10:04:46 AM UTC-7, Anton Ertl wrote:
>> For FIND, Gforth's FIND has produced different xts depending on STATE
>> for 19 years, and there have been no mistakes reported. That's
>> because the usual use of FIND is in user-defined text interpreters,
>> and for that use you actually want the xt representing the
>> interpretation semantics in interpret state and the xt representing
>> the compilation semantics in compile state. Concerning other uses of
>> FIND, they are rare and usually don't involve S" and friends.
>
>So, you insulted me by saying that I "better read" your paper on the evils =
>of state-smart words --- but now you tell us that FIND in gForth is state-s=
>mart and it returns a different xt for the same look-up string depending up=
>on what STATE is at the time that FIND is executed. WTF???
When implementing the dual-xt solution for implementing S" and TO, I
had to decide what xt the words ' FIND and SEARCH-WORDLIST produce.
For FIND, the main use seems to be in user-defined text interpreters,
so I made FIND work for that; the result is that the xt returned by
FIND depends on STATE. I did not like that, but that's the way to do
FIND with such a dual-xt system (and it is hinted at in the standard).
Given that there have been no complaints about Gforth's FIND, I think
the choice was right (the one for ' was more questionable).
My long-term idea was to treat FIND as legacy, and write new
user-defined text interpreters along the lines of
parse-name find-name dup 0= -13 and throw
state @ if
name>compile
else
name>interpret
then
execute
(number handling elided for simplicity of exposition).
>Also, FIND is non-immediate in gForth, so the only way to execute it in com=
>pilation mode is to put it inside of an immediate word.
The usual way is to have it in a text interpreter, and that text
interpreter interprets, e.g., ":", at some point.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-29 03:21 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmq6gu$lc8$1@dont-email.me> |
| In reply to | #40105 |
Anton Ertl wrote: > When implementing the dual-xt solution for implementing S" and TO, I > had to decide what xt the words ' FIND and SEARCH-WORDLIST produce. BTW: is there any reason why SEARCH-WORDLIST is *not* STATE-smart? I just recently added a scope-specific recognizer (in the form <voc>:<name>), and I used (SEARCH-WORDLIST) for that for other reasons, too (it returns the nt, which is then used by Gforth's R:WORD), but that was one reason I had to use it: SEARCH-WORDLIST can't be used as component for your own interpreter. Note that the standard has two different stories on FIND and SEARCH-WORDLIST regarding the ambiguous condition with respect to STATE, and that comes from cmForth, where there's another vocabulary on top in compilation state, and that for sure doesn't apply to SEARCH-WORDLIST. However, Gforth's dual-xt nature is different, so it has to apply to SEARCH- WORDLIST, or SEARCH-WORDLIST is not usable as component for e.g. a scope- recognizer. : ]find[ state @ >r ] find r> 0= IF postpone [ THEN ; ok : ]search-wordlist[ state @ >r ] search-wordlist r> 0= IF postpone [ THEN ; ok s" to" pad place pad find . hex. 1 $7F5447AE3570 ok s" to" pad place pad [find] . hex. 1 $7F5447AE35D8 ok s" to" forth-wordlist search-wordlist . hex. 1 $7F5447AE3570 ok s" to" forth-wordlist [search-wordlist] . hex. 1 $7F5447AE3570 ok That's not quite what I expected. No complaints for 19 years apparently may not mean anything ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-30 07:14 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun30.091425@mips.complang.tuwien.ac.at> |
| In reply to | #40112 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> When implementing the dual-xt solution for implementing S" and TO, I
>> had to decide what xt the words ' FIND and SEARCH-WORDLIST produce.
>
>BTW: is there any reason why SEARCH-WORDLIST is *not* STATE-smart?
Certainly:
1) The specification of SEARCH-WORDLIST does not specify that it may
produce different xts depending on STATE.
2) SEARCH-WORDLIST is not used in text interpreters.
>However, Gforth's dual-xt nature is different, so it has to apply to SEARCH-
>WORDLIST, or SEARCH-WORDLIST is not usable as component for e.g. a scope-
>recognizer.
You have to go beyond the standard to define recognizers, so there is
no reason to stick with a legacy interface like SEARCH-WORDLIST (or
FIND). Using (SEARCH-WORDLIST) is the way to go (although the name
could be improved).
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-01 00:33 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mmv5dg$p4q$1@dont-email.me> |
| In reply to | #40130 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >> >>> When implementing the dual-xt solution for implementing S" and TO, I >>> had to decide what xt the words ' FIND and SEARCH-WORDLIST produce. >> >>BTW: is there any reason why SEARCH-WORDLIST is *not* STATE-smart? > > Certainly: > > 1) The specification of SEARCH-WORDLIST does not specify that it may > produce different xts depending on STATE. > > 2) SEARCH-WORDLIST is not used in text interpreters. 1) is from the standard text, and a result of the dual-xt implementation in cmForth (which doesn't affect SEARCH-WORDLIST). 2) is silly. Why not? "Propper Forth police" requirement? I've often witten something like my scope recognizer just as a parsing word, which is essentially : Forth: ( "name" -- .. ) parse-name forth-wordlist search-wordlist dup 0= -13 throw 0> IF execute ELSE compile, THEN ; immediate I use this to avoid conflicts with words defined in the app dictionary which hide Forth names. Of course, using a recognizer for that is better. forth:s" bla" does work in both interpretation and compilation mode, and forth: s" bla" (as defined above) should, too. >>However, Gforth's dual-xt nature is different, so it has to apply to >>SEARCH- WORDLIST, or SEARCH-WORDLIST is not usable as component for e.g. a >>scope- recognizer. > > You have to go beyond the standard to define recognizers, so there is > no reason to stick with a legacy interface like SEARCH-WORDLIST (or > FIND). Indeed. But if we had a standard on recognizers, I migth want to write that scope-recognizer using standard words only. > Using (SEARCH-WORDLIST) is the way to go (although the name > could be improved). Yes. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-04 13:58 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jul4.155835@mips.complang.tuwien.ac.at> |
| In reply to | #40176 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>
>>>> When implementing the dual-xt solution for implementing S" and TO, I
>>>> had to decide what xt the words ' FIND and SEARCH-WORDLIST produce.
>>>
>>>BTW: is there any reason why SEARCH-WORDLIST is *not* STATE-smart?
>>
>> Certainly:
>>
>> 1) The specification of SEARCH-WORDLIST does not specify that it may
>> produce different xts depending on STATE.
>>
>> 2) SEARCH-WORDLIST is not used in text interpreters.
>
>1) is from the standard text, and a result of the dual-xt implementation in
>cmForth (which doesn't affect SEARCH-WORDLIST).
That that's related to cmForth is a plausible theory. In any case,
the specification does not contain the weaselwording that FIND
contains to allow different xts for different STATEs.
>2) is silly. Why not? "Propper Forth police" requirement?
Because there is FIND for that. Anyway, when we added the "dual-xt"
approach to Gforth, we discussed what to do about SEARCH-WORDLIST and
FIND. You suggested that both produce an xt representing the
interpretation semantics; apparently then we got some input from the
Forth-94 people that suggested that FIND return different xts in
different STATEs. Then I asked Loring Craymer about SEARCH-WORDLIST,
and reported my then-current thoughts as follows:
|The interface looks much like that of FIND, suggesting similar
|behaviour. However, I would not like to have state-dependent behaviour
|for SEARCH-WORDLIST, as I would use it in situations very different
|from FIND. Moreover, the standard says about FIND: "For a given
|string, the values returned by FIND while compiling may differ from
|those returned while not compiling.", but does not say such a thing
|about SEARCH-WORDLIST. So, the most straight-forward implementation
|would be to return an xt identifying the interpretation
|semantics. However, for that version it hardly makes sense to return a
|flag specifying non-default compilation semantics; immediacy makes a
|bit more sense, but mainly on systems where immediacy is the only way
|to do non-default compilation semantics.
It seems that Loring Craymer answered that SEARCH-WORDLIST should work
like FIND (including STATE-dependence), but I wanted to wait for the
official answer for RFI0008 (which never appeared) before taking that
route (and you agreed with that). And it seems that nothing has
happened with SEARCH-WORDLIST since then.
>I've often
>witten something like my scope recognizer just as a parsing word, which is
>essentially
>
>: Forth: ( "name" -- .. ) parse-name forth-wordlist search-wordlist
> dup 0= -13 throw 0> IF execute ELSE compile, THEN ; immediate
I think that this would compile normal words in interpret state. You
probably don't want that.
>I use this to avoid conflicts with words defined in the app dictionary which
>hide Forth names. Of course, using a recognizer for that is better.
>
>forth:s" bla" does work in both interpretation and compilation mode, and
>forth: s" bla" (as defined above) should, too.
No need for SEARCH-WORDLIST for that:
: Forth: ( "name" .. -- .. )
forth-wordlist >order
parse-name ['] evaluate catch
previous throw ;
Or if you want an error if the name is not in the forth-wordlist:
: Forth: ( "name" .. -- .. )
get-order n>r forth-wordlist 1 set-order
parse-name ['] evaluate catch
nr> set-order throw ;
Both untested.
>>>However, Gforth's dual-xt nature is different, so it has to apply to
>>>SEARCH- WORDLIST, or SEARCH-WORDLIST is not usable as component for e.g. a
>>>scope- recognizer.
>>
>> You have to go beyond the standard to define recognizers, so there is
>> no reason to stick with a legacy interface like SEARCH-WORDLIST (or
>> FIND).
>
>Indeed. But if we had a standard on recognizers, I migth want to write that
>scope-recognizer using standard words only.
Then propose adding (SEARCH-WORDLIST) (with a better name) to the
standard.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-07-05 00:18 +0200 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mn9m0n$mjk$1@dont-email.me> |
| In reply to | #40280 |
Anton Ertl wrote: >>2) is silly. Why not? "Propper Forth police" requirement? > > Because there is FIND for that. FIND doesn't work too well for the scope-specific search example. >>: Forth: ( "name" -- .. ) parse-name forth-wordlist search-wordlist >>dup 0= -13 throw 0> IF execute ELSE compile, THEN ; immediate > > I think that this would compile normal words in interpret state. You > probably don't want that. Yes, that's the compile-only version, here's the state-smart version: : Forth: ( "name" -- .. ) parse-name forth-wordlist search-wordlist dup 0= -13 and throw 0> state @ 0= or IF execute ELSE compile, THEN ; immediate This one fails on : test forth: s" bla" ; in Gforth. It works fine on VFX (yes, really, the SET-COMPILER s" there doesn't cause problems, whereas the dual-xt s" in Gforth does - or let's say the combination of dual-xt and SEARCH-WORDLIST ;-). I think we can't wait for RFI0008 to be answered, the TC doesn't exist anymore. IMHO the two possible answers are: 1. If we feel that dual-xt within one wordlist is legitimate (as opposed to cmForth dual-xt with the COMPILER wordlist), then SEARCH-WORDLIST should do the same weasel-worded stuff as FIND. 2. If the standard wants to indicate that dual-xt is only supposed to be implemented as COMPILER wordlist, SEARCH-WORDLIST is fine. And Gforth is broken. Pick one. In Gforth, we, as implementers, pretty much don't use SEARCH-WORDLIST, but (SEARCH-WORDLIST) instead, which doesn't have the problem. Therefore, the most urgent think for us is to give (SEARCH-WORDLIST) a better name. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-05 07:33 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnaj0d$5ia$1@dont-email.me> |
| In reply to | #40286 |
on 04/07/2015 23:18:14, Bernd Paysan wrote: > (SEARCH-WORDLIST) FIND-WORD ( c-addr u wid –– 0 | xt 1 | xt -1 ). Standardise FIND-NAME ( c-addr u wid –– 0 | nt ) at the same time.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-05 08:28 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnam8o$dph$1@dont-email.me> |
| In reply to | #40294 |
on 05/07/2015 07:33:10, "Alex McDonald" wrote: > on 04/07/2015 23:18:14, Bernd Paysan wrote: >> (SEARCH-WORDLIST) > > FIND-WORD ( c-addr u wid –– 0 | xt 1 | xt -1 ). Standardise FIND-NAME > ( c-addr u wid –– 0 | nt ) at the same time. > Correction; no WID in FIND-NAME. FIND-NAME ( c-addr u –– 0 | nt )
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-07-05 12:22 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <55991d60.337125477@news.eternal-september.org> |
| In reply to | #40286 |
On Sun, 05 Jul 2015 00:18:18 +0200, Bernd Paysan <bernd.paysan@gmx.de>
wrote:
> dup 0= -13 and throw 0> state @ 0= or
> IF execute ELSE compile, THEN ; immediate
>
>This one fails on
>
>: test forth: s" bla" ;
>
>in Gforth. It works fine on VFX (yes, really, the SET-COMPILER s" there
>doesn't cause problems, whereas the dual-xt s" in Gforth does - or let's say
>the combination of dual-xt and SEARCH-WORDLIST ;-).
>
>I think we can't wait for RFI0008 to be answered, the TC doesn't exist
>anymore. IMHO the two possible answers are:
>
>1. If we feel that dual-xt within one wordlist is legitimate (as opposed to
>cmForth dual-xt with the COMPILER wordlist), then SEARCH-WORDLIST should do
>the same weasel-worded stuff as FIND.
>
>2. If the standard wants to indicate that dual-xt is only supposed to be
>implemented as COMPILER wordlist, SEARCH-WORDLIST is fine. And Gforth is
>broken.
>
>Pick one.
Before we make such a choice we should decide what we want a Forth to
do and how to construct it. For example, should the traditional text
interpreter implementation remain standard:
begin
bl word dup c@ while
find dup if
state @ 0< and if
compile,
else
execute
then
else
drop count undefined
then
repeat
As someone reminded me recently, this loop with traditional or modern
implementation techniques has served us well for nearly 40 years.
It's simple. I see no no virtue in spoiling the essential simplicity
of Forth.
We need to decide how to deal with the corner cases that the ANS
document introduced. The vast majority of these corner cases have
no impact on real programs. I say this after being involved in the
port of a 1,000,000 line of source code app from a custom Forth
to an MPE direct-threaded Forth-83 system and then to VFX Forth
for Windows.
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-07-06 16:03 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jul6.180302@mips.complang.tuwien.ac.at> |
| In reply to | #40310 |
stephen@mpeforth.com (Stephen Pelc) writes:
>For example, should the traditional text
>interpreter implementation remain standard:
>
> begin
> bl word dup c@ while
> find dup if
> state @ 0< and if
> compile,
> else
> execute
> then
> else
> drop count undefined
> then
> repeat
>
>As someone reminded me recently, this loop with traditional or modern
>implementation techniques has served us well for nearly 40 years.
>It's simple. I see no no virtue in spoiling the essential simplicity
>of Forth.
All the existing approaches work with the traditional user-defined
text interpreter. As I wrote recently in the Forth200x mailing list
<20150625120346.GA32156@a4.complang.tuwien.ac.at>:
|The difference between these models is the time in the text
|interpretation when the decision is made between interpretation and
|compilation semantics. We have the following steps when processing a
|word in the text interpreter:
|
|1) parse the name
|2) lookup the dictionary entry
|3) in the dictionary entry, access the interpretation or compilation semantics
|4) depending on STATE and immediate flag, EXECUTE or COMPILE,
|5) perform the word through EXECUTE (in interpret state and for immediate words)
|
|When processing a word like S" (with non-default and non-immediate
|compilation semantics),
|
|* cmForth chooses between interpretation and compilation semantics in
| step 2).
|
|* Gforth chooses between the semantics in step 3).
|
|* VFX chooses between the semantics in step 4) (by delivering a
| non-immediate flag for S" and having a non-standard COMPILE, that
| performs the compilation semantics of S" instead of appending the
| same semantics that EXECUTE would perform).
|
|* STATE-smart words choose between the semantics in step 5), by
| explicitly querying STATE. They are immediate, so that step 5
| happens.
|
|That all works nicely in the text interpreter:
|
|The STATE-smart approach works in the text interpreter because STATE
|does not change between step 1 and step 5.
|
|The VFX approach works in the text interpreter, because the
|non-standard COMPILE, is not directly visible there.
|
|The STATE-smart approach can fail outside the text interpreter if
|STATE is not the state intended by the programmer; this can happen is
|the STATE-smart word is ticked or POSTPONEd.
|
|The VFX approach fails if the xt of such a word is passed to code that
|contains COMPILE, and expects the COMPILE, appending the same
|semantics that EXECUTE would perform (i.e., what the standard
|specifies).
I did not get the text interpreter above to work with
VFX, so I tried to use the one from the standard document:
: int
\ upper case code comes from the standard
begin
bl word
dup c@ 0= if drop exit then \ leave at end of line
FIND ?DUP IF ( xt +-1 )
STATE @ IF ( xt +-1 )
0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
ELSE ( xt +-1 )
DROP EXECUTE ( ??? )
THEN
ELSE ( c-addr )
-13 throw \ numbers are left as an exercise
THEN
again ;
int : test dup if swap then ;
see test
2 0 test . .
I have tested this on VFX, SwiftForth, and Gforth, and it works on all
of them.
Now let's do a small variation:
: int
\ upper case code comes from the standard
begin
bl word
dup c@ 0= if drop exit then \ leave at end of line
FIND ?DUP IF ( xt +-1 )
STATE @ IF ( xt +-1 )
0> IF EXECUTE ELSE dup COMPILE, . THEN ( ??? )
ELSE ( xt +-1 )
DROP EXECUTE ( ??? )
THEN
ELSE ( c-addr )
-13 throw \ numbers are left as an exercise
THEN
again ;
int : test dup if swap then ;
see test
2 0 test . .
This variation prints out the values passed to COMPILE,. Since
COMPILE, has the stack effect ( xt -- ), if the code above works, this
should work, too. It works in Gforth and SwiftForth, but in VFX the
resulting code is:
( 080C0910 85DB ) TEST EBX, EBX
( 080C0912 0F84FAFFFFFF ) JZ/E 080C0912
( 080C0918 8BD3 ) MOV EDX, EBX
( 080C091A 8B5D00 ) MOV EBX, [EBP]
( 080C091D 895500 ) MOV [EBP], EDX
( 080C0920 C3 ) NEXT,
Note that the instruction at 080C0912 jumps to itself, producing an
endless loop for the given test data.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-06 18:40 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mneefn$649$1@dont-email.me> |
| In reply to | #40368 |
on 06/07/2015 17:02:58, anton wrote: > > Now let's do a small variation: > >: int > \ upper case code comes from the standard > begin > bl word > dup c@ 0= if drop exit then \ leave at end of line > FIND ?DUP IF ( xt +-1 ) > STATE @ IF ( xt +-1 ) > 0> IF EXECUTE ELSE dup COMPILE, . THEN ( ??? ) > ELSE ( xt +-1 ) > DROP EXECUTE ( ??? ) > THEN > ELSE ( c-addr ) > -13 throw \ numbers are left as an exercise > THEN > again ; > int : test dup if swap then ; > see test > 2 0 test . . > > This variation prints out the values passed to COMPILE,. Since > COMPILE, has the stack effect ( xt -- ), if the code above works, this > should work, too. It works in Gforth and SwiftForth, but in VFX the > resulting code is: This fails on my Forth. COMPILE, of IF gives( xt -- orig ) on the stack, and . prints the last cell of ORIG.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-07-06 20:36 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <559ae58a.453903192@news.eternal-september.org> |
| In reply to | #40368 |
On Mon, 06 Jul 2015 16:03:02 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >I have tested this on VFX, SwiftForth, and Gforth, and it works on all >of them. > >Now let's do a small variation: > >: int >\ upper case code comes from the standard >begin > bl word > dup c@ 0= if drop exit then \ leave at end of line > FIND ?DUP IF ( xt +-1 ) > STATE @ IF ( xt +-1 ) > 0> IF EXECUTE ELSE dup COMPILE, . THEN ( ??? ) > ELSE ( xt +-1 ) > DROP EXECUTE ( ??? ) > THEN > ELSE ( c-addr ) > -13 throw \ numbers are left as an exercise > THEN >again ; >int : test dup if swap then ; >see test >2 0 test . . > >This variation prints out the values passed to COMPILE,. Since >COMPILE, has the stack effect ( xt -- ), if the code above works, this >should work, too. It works in Gforth and SwiftForth, but in VFX the >resulting code is: > >( 080C0910 85DB ) TEST EBX, EBX >( 080C0912 0F84FAFFFFFF ) JZ/E 080C0912 >( 080C0918 8BD3 ) MOV EDX, EBX >( 080C091A 8B5D00 ) MOV EBX, [EBP] >( 080C091D 895500 ) MOV [EBP], EDX >( 080C0920 C3 ) NEXT, > >Note that the instruction at 080C0912 jumps to itself, producing an >endless loop for the given test data. As Alex has pointed out, the test code is wrong. As I'm sure you are aware, the point of my post was to suggest that there is real value in keeping parts of traditional Forth. Obsessing about VFX with broken test code does not help. Let's stick to the approach required to get the next standard document built. 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-07-07 07:18 +0100 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mnfqsr$i82$1@dont-email.me> |
| In reply to | #40371 |
on 06/07/2015 21:36:17, wrote: > On Mon, 06 Jul 2015 16:03:02 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: >>I have tested this on VFX, SwiftForth, and Gforth, and it works on all >>of them. >> >>Now let's do a small variation: >> >>: int >>\ upper case code comes from the standard >>begin >> bl word >> dup c@ 0= if drop exit then \ leave at end of line >> FIND ?DUP IF ( xt +-1 ) >> STATE @ IF ( xt +-1 ) >> 0> IF EXECUTE ELSE dup COMPILE, . THEN ( ??? ) >> ELSE ( xt +-1 ) >> DROP EXECUTE ( ??? ) >> THEN >> ELSE ( c-addr ) >> -13 throw \ numbers are left as an exercise >> THEN >>again ; >>int : test dup if swap then ; >>see test >>2 0 test . . >> >>This variation prints out the values passed to COMPILE,. Since >>COMPILE, has the stack effect ( xt -- ), if the code above works, this >>should work, too. It works in Gforth and SwiftForth, but in VFX the >>resulting code is: >> >>( 080C0910 85DB ) TEST EBX, EBX >>( 080C0912 0F84FAFFFFFF ) JZ/E 080C0912 >>( 080C0918 8BD3 ) MOV EDX, EBX >>( 080C091A 8B5D00 ) MOV EBX, [EBP] >>( 080C091D 895500 ) MOV [EBP], EDX >>( 080C0920 C3 ) NEXT, >> >>Note that the instruction at 080C0912 jumps to itself, producing an >>endless loop for the given test data. > > As Alex has pointed out, the test code is wrong. I suspect Anton will point out that COMPILE, is the equivalent of , and that IF (classically an IMMEDIATE) should compile on the EXECUTE leg. > > As I'm sure you are aware, the point of my post was to suggest that > there is real value in keeping parts of traditional Forth. Obsessing > about VFX with broken test code does not help. Let's stick to the > approach required to get the next standard document built. > > Stephen >
[toc] | [prev] | [next] | [standalone]
Page 11 of 26 — ← Prev page 1 … 9 10 [11] 12 13 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web