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 12 of 26 — ← Prev page 1 … 10 11 [12] 13 14 … 26 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-07 07:17 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jul7.091731@mips.complang.tuwien.ac.at> |
| In reply to | #40386 |
"Alex McDonald" <blog@rivadpm.com> writes:
>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.
If you mean <mneefn$649$1@dont-email.me>:
|This fails on my Forth. COMPILE, of IF gives( xt -- orig ) on the stack,
|and . prints the last cell of ORIG.
He points out no such thing. Instead, he points out that his Forth
system has a similar bug as VFX Forth.
>I suspect Anton will point out that COMPILE, is the equivalent of , and
>that IF (classically an IMMEDIATE) should compile on the EXECUTE leg.
Yes, given the specified stack effect of "COMPILE,", COMPILE,ing the
xt of IF must not perform the compilation semantics of IF; therefore,
if you want the traditional text interpreter to work, FIND has to
report IF as immediate, and EXECUTEing the resulting xt has to perform
the compilation semantics of IF.
Of course, you could hide behind the fact that FINDing IF is an
ambuguous condition, but if you want the traditional text interpreter
to be standard, you won't do that.
>> 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.
Yes, there is real value in that. If you want traditional things to
work, you need to be more traditional in your Forth implementation.
Some innovations work (using COMPILE, for optimizing normal words),
others don't, at least not always (using COMPILE, for non-default
compilation semantics); it's fine if you try that, but if people point
out where it fails, be prepared to go back.
- 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-06-28 19:32 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <87si9butvz.fsf@nightsong.com> |
| In reply to | #40105 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > 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 ... I've wondered how un-Forth it would be to make state an integer instead of a flag. That would allow writing stuff like infix parsers with traditional methods like pushdown automata.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-28 19:32 -1000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <KfqdnRydZJTJRQ3InZ2dnUU7-eGdnZ2d@supernews.com> |
| In reply to | #40113 |
On 6/28/15 4:32 PM, Paul Rubin wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> 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 ... > > I've wondered how un-Forth it would be to make state an integer instead > of a flag. That would allow writing stuff like infix parsers with > traditional methods like pushdown automata. It is an integer. According to Forth2012, "The true value in STATE is non-zero, but is otherwise implementation-defined." So it can certainly be, for example, the xt of a word to handle compilation. FORTH, Inc. has used it this way for some years. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-06-29 15:06 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <87a8viuq3m.fsf@nightsong.com> |
| In reply to | #40114 |
"Elizabeth D. Rather" <erather@forth.com> writes:
> It is an integer. According to Forth2012, "The true value in STATE is
> non-zero, but is otherwise implementation-defined." So it can
> certainly be, for example, the xt of a word to handle
> compilation. FORTH, Inc. has used it this way for some years.
Well, I was thinking in terms of user-written or otherwise hacky text
interpreters. Example: say you use Forth 200x-style locals,
: foo {: x y | z -- :} .... ;
One way to compile this is to make {: a parsing word that reads tokens
until it sees the :}. Another is use state, so that
state = 0 => interpreter
state = 1 => inside normal colon definition
state = 2 => inside a {: ... :} but before the |
state = 3 => inside a {: ... :} after the | but before the --
state = 4 => inside a {: ... :} and after the --
Then the semantics of individual words could switch on state. So {: in
state 1 would set state to 2, after which any word with no special state
2 semantics would emit code to pop the data stack onto a locals stack,
and generate a temporary dictionary entry that remembers how many locals
items had been pushed. | would switch to state 3. Non-special names in
state 3 would do the same as state 2, except they'd push a 0 on the
locals stack instead of copying from the data stack. -- would set state
to 4 and remember the total number of items pushed on the locals stack
so that the variable could be found by indexing into it, and names in
state 4 would do nothing. :} would go back to state 1.
I don't know whether the above is better or worse than making {: into a
parsing word, in terms of forthiness.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-30 07:48 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jun30.094837@mips.complang.tuwien.ac.at> |
| In reply to | #40121 |
Paul Rubin <no.email@nospam.invalid> writes:
>Well, I was thinking in terms of user-written or otherwise hacky text
>interpreters. Example: say you use Forth 200x-style locals,
>
> : foo {: x y | z -- :} .... ;
>
>One way to compile this is to make {: a parsing word that reads tokens
>until it sees the :}. Another is use state, so that
>
> state = 0 => interpreter
> state = 1 => inside normal colon definition
> state = 2 => inside a {: ... :} but before the |
> state = 3 => inside a {: ... :} after the | but before the --
> state = 4 => inside a {: ... :} and after the --
>
>Then the semantics of individual words could switch on state. So {: in
>state 1 would set state to 2, after which any word with no special state
>2 semantics would emit code to pop the data stack onto a locals stack,
>and generate a temporary dictionary entry that remembers how many locals
>items had been pushed. | would switch to state 3. Non-special names in
>state 3 would do the same as state 2, except they'd push a 0 on the
>locals stack instead of copying from the data stack. -- would set state
>to 4 and remember the total number of items pushed on the locals stack
>so that the variable could be found by indexing into it, and names in
>state 4 would do nothing. :} would go back to state 1.
>
>I don't know whether the above is better or worse than making {: into a
>parsing word, in terms of forthiness.
Better: {: | -- :} are pretty simple, and stand for themselves, and
leave the parsing etc. to the text interpreter, like : and [ (but
there are people who defend parsing [).
Worse: Existing user-defined text interpreters would not work.
Worse: It is not extendible: There is no mechanism to add additional
states for the next {:.
In Gforth {: stands for itself, by pushing a special wordlist on the
search order that recognizes everything and defines it as a local
(plus another wordlist that contains | -- :} among other things). I
guess once we have standard recognizers, one can use this approach in
a standard implementation of {:.
If we had a way to extend the states, and to let user-defined text
interpreters access the meaning of the extended states, then one could
go for your approach, but are there any uses that cannot be done just
as well with other approaches?
- 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 | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-06-30 03:38 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <ed701b59-0e0a-4483-a17e-b4ca60e945fe@googlegroups.com> |
| In reply to | #40133 |
Le mardi 30 juin 2015 10:06:46 UTC+2, Anton Ertl a écrit :
>
> If we had a way to extend the states, and to let user-defined text
> interpreters access the meaning of the extended states, then one could
> go for your approach, but are there any uses that cannot be done just
> as well with other approaches?
>
> - anton
> --
Hi,
I don't know how quotations are implémented in ANS Forth, but, in Oforth,
state is incremented each time a block is nested into another.
: test { | i | #[ #[ 5 loop: i [ i . ] ] times(5) ] bench }
test
1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 7064
ok
Each time #[ is performed, it increments the state value :
- At the interpreter level, state is 0
- Into test, state is 1.
- Into the first block state is 2.
- Into the nested block, state is 3.
- ...
Interpreter is considered into compile state if state > 0
This also allows to create blocks directly at interpreter level :
12 #[ 10 + ] times(5) .
62 ok
Into the block, state value is 1 and interpreter is into compile mode.
Other approachs are possible, but I find this one very simple
to implement nested quotations and closures.
Regards,
Franck
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-30 04:44 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <df9f8f51-2dd3-457d-b0f4-416e2d465b87@googlegroups.com> |
| In reply to | #40141 |
marți, 30 iunie 2015, 13:38:35 UTC+3, franck....@gmail.com a scris:
> Le mardi 30 juin 2015 10:06:46 UTC+2, Anton Ertl a écrit :
> >
> > If we had a way to extend the states, and to let user-defined text
> > interpreters access the meaning of the extended states, then one could
> > go for your approach, but are there any uses that cannot be done just
> > as well with other approaches?
> >
> > - anton
> > --
>
> Hi,
>
> I don't know how quotations are implémented in ANS Forth, but, in Oforth,
> state is incremented each time a block is nested into another.
>
> : test { | i | #[ #[ 5 loop: i [ i . ] ] times(5) ] bench }
> test
> 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 7064
> ok
>
> Each time #[ is performed, it increments the state value :
> - At the interpreter level, state is 0
> - Into test, state is 1.
> - Into the first block state is 2.
> - Into the nested block, state is 3.
> - ...
>
> Interpreter is considered into compile state if state > 0
>
My state is exactly like that. I support embedded quotations or anonymous
definitions of any level. In fact it is named "level" but I published
it "state" in the dictionary to sound like in classical forth.
> This also allows to create blocks directly at interpreter level :
> 12 #[ 10 + ] times(5) .
> 62 ok
>
I don't support this, only compiled quotations. I can only write something
like for example:
def 10+times5 5 [ 10 + ] times ;
12 10+times5 .
62 ok
> Into the block, state value is 1 and interpreter is into compile mode.
>
> Other approachs are possible, but I find this one very simple
> to implement nested quotations and closures.
>
Me too :)
> Regards,
> Franck
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2015-07-01 02:49 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <f6f5336e-7c64-4c8a-8b85-0433ceb5c09b@googlegroups.com> |
| In reply to | #40143 |
Le mardi 30 juin 2015 13:44:01 UTC+2, Raimond Dragomir a écrit : > > Each time #[ is performed, it increments the state value : > > - At the interpreter level, state is 0 > > - Into test, state is 1. > > - Into the first block state is 2. > > - Into the nested block, state is 3. > > - ... > > > > Interpreter is considered into compile state if state > 0 > > > My state is exactly like that. I support embedded quotations or anonymous > definitions of any level. In fact it is named "level" but I published > it "state" in the dictionary to sound like in classical forth. > Interesting ! Not the first time I notice some convergence of design with your system. For instance, I think I have read that your words are tagged (data or code). Oforth words (not a surprise) are objects created into the dictionary. (Constant, Class, Property, Functions, Method, ...). And Oforth interpreter is working according to words type. Your tag on words are similar, I think ... and not far from objects, after all ... :) I don't have much time right now, but I would be interested to test your Forth. Is it available (Linux or Windows) ? Franck
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-01 04:43 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <290c74ca-b8a3-4805-8c2a-38c1a8e11f88@googlegroups.com> |
| In reply to | #40192 |
miercuri, 1 iulie 2015, 12:49:33 UTC+3, franck....@gmail.com a scris: > Le mardi 30 juin 2015 13:44:01 UTC+2, Raimond Dragomir a écrit : > > > Each time #[ is performed, it increments the state value : > > > - At the interpreter level, state is 0 > > > - Into test, state is 1. > > > - Into the first block state is 2. > > > - Into the nested block, state is 3. > > > - ... > > > > > > Interpreter is considered into compile state if state > 0 > > > > > My state is exactly like that. I support embedded quotations or anonymous > > definitions of any level. In fact it is named "level" but I published > > it "state" in the dictionary to sound like in classical forth. > > > > Interesting ! > > Not the first time I notice some convergence of design with your system. > > For instance, I think I have read that your words are tagged (data or code). > > Oforth words (not a surprise) are objects created into the dictionary. > (Constant, Class, Property, Functions, Method, ...). > And Oforth interpreter is working according to words type. > > Your tag on words are similar, I think ... and not far from objects, after > all ... :) > > I don't have much time right now, but I would be interested to test your > Forth. Is it available (Linux or Windows) ? > > Franck As long as you can compile a single c file ... :) With gcc, mingw for windows. I'm a windows guy, but I'm testing my system on two different platforms: 1. windows 32bit x86 2. linux cortex-a8 arm, specifically a beagle bone black and a cubie board (both with some debian distro and off-the-shelf gcc) This ensures me of some kind of portability. I had at some point in time a STC native implementation. It was for 32bit x86 but when I thought of using it on my BBB I switched on some kind of tokenized code. It's a bit slower but it's kind of dual mode system, it's a toikenized code over the native calls, so you (I, somebody) can mixed the code generation if you really want... Anyway, the tokenized code is sooo compact :) For example my test suite compiles to 2222 bytes of code and 5816 bytes of dictionary... (dictionary space is totally separated - I'm thinking of embedded systems where the real microcontroller memory is quite small, but the dictionary may be stored in an external spi flash memory for example) My forth and your forth cannot be the same though... yours is kind of dynamic language, mine is static. I didn't publish it yet, I really don't know how and where. I did start some kind of documentation though. I'm documenting know the differences from a standard forth. Mail me and you can get a copy of everything. It's really nothing close sourced. Maybe you can advice me of how to make it public.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-07-02 02:16 -0400 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <mn2kt1$4jh$1@dont-email.me> |
| In reply to | #40194 |
On 7/1/2015 7:43 AM, Raimond Dragomir wrote: > miercuri, 1 iulie 2015, 12:49:33 UTC+3, franck....@gmail.com a scris: >> Le mardi 30 juin 2015 13:44:01 UTC+2, Raimond Dragomir a écrit : >>>> Each time #[ is performed, it increments the state value : >>>> - At the interpreter level, state is 0 >>>> - Into test, state is 1. >>>> - Into the first block state is 2. >>>> - Into the nested block, state is 3. >>>> - ... >>>> >>>> Interpreter is considered into compile state if state > 0 >>>> >>> My state is exactly like that. I support embedded quotations or anonymous >>> definitions of any level. In fact it is named "level" but I published >>> it "state" in the dictionary to sound like in classical forth. >>> >> >> Interesting ! >> >> Not the first time I notice some convergence of design with your system. >> >> For instance, I think I have read that your words are tagged (data or code). >> >> Oforth words (not a surprise) are objects created into the dictionary. >> (Constant, Class, Property, Functions, Method, ...). >> And Oforth interpreter is working according to words type. >> >> Your tag on words are similar, I think ... and not far from objects, after >> all ... :) >> >> I don't have much time right now, but I would be interested to test your >> Forth. Is it available (Linux or Windows) ? >> >> Franck > > As long as you can compile a single c file ... :) > With gcc, mingw for windows. > I'm a windows guy, but I'm testing my system on two different platforms: > 1. windows 32bit x86 > 2. linux cortex-a8 arm, specifically a beagle bone black and a cubie board > (both with some debian distro and off-the-shelf gcc) > This ensures me of some kind of portability. > I had at some point in time a STC native implementation. It was for 32bit x86 > but when I thought of using it on my BBB I switched on some kind of > tokenized code. It's a bit slower but it's kind of dual mode system, it's > a toikenized code over the native calls, so you (I, somebody) can mixed > the code generation if you really want... > Anyway, the tokenized code is sooo compact :) For example my test suite > compiles to 2222 bytes of code and 5816 bytes of dictionary... (dictionary > space is totally separated - I'm thinking of embedded systems where > the real microcontroller memory is quite small, but the dictionary may > be stored in an external spi flash memory for example) > > My forth and your forth cannot be the same though... yours is kind of > dynamic language, mine is static. > > I didn't publish it yet, I really don't know how and where. I did start some > kind of documentation though. I'm documenting know the differences from > a standard forth. > > Mail me and you can get a copy of everything. It's really nothing close sourced. > Maybe you can advice me of how to make it public. Anyone have an idea of how long this thread is? It is way off topic and oddly enough, Hugh is the only person still posting on topic (well sort of) by ranting about how no one knows forth but him. Can I ask nicely that you guys start a new thread so I can flag this one for T'bird to ignore so I don't have to read all of Hugh's crap but can still read your posts on this topic? BTW, I would love to see a forth system targeted to ARM chips (and/or the MSP430) that keeps the dictionary on the host other than the executable portions. But maybe this is not really important. Mecrisp seems to support reasonably small targets, just not the really small ones. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-01 23:24 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <87twtnoz51.fsf@nightsong.com> |
| In reply to | #40227 |
rickman <gnuarm@gmail.com> writes: > BTW, I would love to see a forth system targeted to ARM chips (and/or > the MSP430) that keeps the dictionary on the host other than the > executable portions. But maybe this is not really important. That's called a tethered Forth and it's implemented in the Swift and VFX products, I thought. But your Stellaris board has enough memory to hold the dictionary for any reasonable Forth project, especially if the dictionary is being written to flash. The smallest 430 Launchpad is another story and getting a resident Forth in it at all takes cutting some corners. But the bigger 430's should work pretty well. The one with 128K of FRAM and a built-in LCD display is on sale right now and I'm tempted to get one even though it will almost surely end up sitting on a shelf with my other Launchpads.
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-07-02 00:10 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <dab5c107-4e5e-4f3b-b97e-8a4a8c09c8bf@googlegroups.com> |
| In reply to | #40227 |
> BTW, I would love to see a forth system targeted to ARM chips (and/or > the MSP430) that keeps the dictionary on the host other than the > executable portions. But maybe this is not really important. Mecrisp > seems to support reasonably small targets, just not the really small ones. > -- > > Rick This is my plan. I have the 'host' part quite ready now. The only 'application' that I'm interested in writing with it is cross-compilers. (although host' can be some bigger embedded systems like BBB or rPi). My dictionary space is separated completely because I want it to be stored anywhere (internal flash, external spi flash, sd card, or even serial link (another machine - typically 'host')). The code is tokenized and it's really compact. It seems that the dictionary is 2.5 times bigger than the real code! My intended target architectures will be: - very small: targets with no REPL. No need of dictionary at all - small: dictionary over the serial link. REPL needs some host special console or terminal program of course. - medium: dictionary on target, target has REPL but only the interpreter (no compiler). Here there are two cases: - dictionary merged with code - in internal flash - dictionary is on an external medium (serial flash, sd card) These cases are only for the cross-compiler to know if it should merge the dictionary with the code. The target kernel will know what medium for the dictionary will have anyway. For this architecture I'm mainly thinking of Cortex-M chips around 32k flash 4K ram. They are a lot. If you afford a serial spi flash on the system (the smallest 512kbytes serial flash costs $0.15 these days lol) you can have the dictionary local, with a standard REPL. - large: typical standalone forth system with REPL interpreter/compiler. I name it large because it "must" provide all the features of the 'host' one: file system (sd card based) with full include file stack, full wordlist support, nested quoations and locals, well everything. Here is a system that will suport the large model (I have a few designs like this): - LPC4088 120MHz Cortex-M4 - 8MB / 32MB SDRAM - 8MB serial quad spi flash - SD card with Chan's fatfs - Ethernet 10/100 with uip stack (I choos uip which is much simpler but works perfectly. I'm building other high level protocols on it) - a cooperative multitasking os (we are forthers, don't we :) For such a system my only problem right now is to decide if I need an editor or not... I can upload files with tftp protocol and then type "include file" in the REPL. I also have 'cat' command to view files. I miss an editor so that the system to be completely standalone.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2015-07-02 01:51 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <87lhezosbg.fsf@nightsong.com> |
| In reply to | #40133 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Another is use state... I don't know whether the above is better or
>>worse than making {: into a parsing word, in terms of forthiness.
> Worse: Existing user-defined text interpreters would not work.
What facilities for user-defined text interpreters exist now? Somehow I
missed that.
> Worse: It is not extendible: There is no mechanism to add additional
> states for the next {:.
Well, the idea is these special words switch on state, and more such
states could be added, by redefinition or through some kind of
extensible matching scheme.
> In Gforth {: stands for itself, by pushing a special wordlist on the
> search order that recognizes everything and defines it as a local
How does the special wordlist match everything? I don't see how to do
that with the gforth wordlist functions. Is this a new extension?
> I guess once we have standard recognizers, one can use this approach
> in a standard implementation of {:.
Hmm I will try to make sense of the recognizer docs that I can find. I
haven't looked at them closely yet.
> If we had a way to extend the states, and to let user-defined text
> interpreters access the meaning of the extended states, then one could
> go for your approach, but are there any uses that cannot be done just
> as well with other approaches?
Using state that way, you could implement textbook-style automata based
parsers. I guess you'd want recognizers too, so you could say
(2*(3+4)) instead of ( 2 * ( 3 + 4 ) ) .
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-02 12:49 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jul2.144953@mips.complang.tuwien.ac.at> |
| In reply to | #40236 |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>Another is use state... I don't know whether the above is better or
>>>worse than making {: into a parsing word, in terms of forthiness.
>> Worse: Existing user-defined text interpreters would not work.
>
>What facilities for user-defined text interpreters exist now? Somehow I
>missed that.
REFILL WORD FIND STATE EXECUTE COMPILE, >NUMBER LITERAL
E.g., as outlined in A.6.2.0945:
... ( c-addr )
FIND ?DUP IF ( xt +-1 )
STATE @ IF ( xt +-1 )
0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
ELSE ( xt +-1 )
DROP EXECUTE ( ??? )
THEN
ELSE ( c-addr )
( whatever you do for an undefined word )
THEN
...
>> Worse: It is not extendible: There is no mechanism to add additional
>> states for the next {:.
>
>Well, the idea is these special words switch on state, and more such
>states could be added, by redefinition or through some kind of
>extensible matching scheme.
Ok, if you outline them, we can discuss them.
>> In Gforth {: stands for itself, by pushing a special wordlist on the
>> search order that recognizes everything and defines it as a local
>
>How does the special wordlist match everything? I don't see how to do
>that with the gforth wordlist functions. Is this a new extension?
No. Gforth has had an object-oriented wordlist implementation for a
long time (before locals were implemented in 1994, to support the
plain linked list and hashed wordlists). This contains a way to
define how a wordlist searches words; in the locals-defining wordlist,
this method always finds the word, and, as a side-effect, defines it.
- 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-07-02 18:02 -0400 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <op.x0515wqtyfako5@localhost> |
| In reply to | #40242 |
On Thu, 02 Jul 2015 08:49:53 -0400, Anton Ertl
<anton@mips.complang.tuwien.ac.at> wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> Another is use state... I don't know whether the above is better or
>>>> worse than making {: into a parsing word, in terms of forthiness.
>>> Worse: Existing user-defined text interpreters would not work.
>>
>> What facilities for user-defined text interpreters exist now?
>> Somehow I missed that.
>
> REFILL WORD FIND STATE EXECUTE COMPILE, >NUMBER LITERAL
>
> E.g., as outlined in A.6.2.0945:
>
> ... ( c-addr )
> FIND ?DUP IF ( xt +-1 )
> STATE @ IF ( xt +-1 )
> 0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
> ELSE ( xt +-1 )
> DROP EXECUTE ( ??? )
> THEN
> ELSE ( c-addr )
> ( whatever you do for an undefined word )
> THEN
> ...
Did you just post a word with STATE in it? Looks like it.
In your opinion, shouldn't the inner interpreter *not* be
STATE-smart too?
Elsehwere in this thread, you said:
> 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.
If you're going to excise STATE-smart words, shouldn't this be
consistent, i.e., done everywhere? I.e., if you can't actually
eliminate the use of the word STATE everywhere, what is the point
of attempting to do so, in part?
Rod Pemberton
--
Tolerance and socialism attracts intolerance and terrorism. See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-07-04 14:31 +0000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <2015Jul4.163105@mips.complang.tuwien.ac.at> |
| In reply to | #40257 |
"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>On Thu, 02 Jul 2015 08:49:53 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>> Paul Rubin <no.email@nospam.invalid> writes:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>>>>> Another is use state... I don't know whether the above is better or
>>>>> worse than making {: into a parsing word, in terms of forthiness.
>>>> Worse: Existing user-defined text interpreters would not work.
>>>
>>> What facilities for user-defined text interpreters exist now?
>>> Somehow I missed that.
>>
>> REFILL WORD FIND STATE EXECUTE COMPILE, >NUMBER LITERAL
>>
>> E.g., as outlined in A.6.2.0945:
>>
>> ... ( c-addr )
>> FIND ?DUP IF ( xt +-1 )
>> STATE @ IF ( xt +-1 )
>> 0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
>> ELSE ( xt +-1 )
>> DROP EXECUTE ( ??? )
>> THEN
>> ELSE ( c-addr )
>> ( whatever you do for an undefined word )
>> THEN
>> ...
>
>Did you just post a word with STATE in it? Looks like it.
>
>In your opinion, shouldn't the inner interpreter *not* be
>STATE-smart too?
That's a text interpreter, not the inner interpreter. The inner
interpreter, like everything else except the text interpreter should
be STATE-indepenent.
The text interpreter is the only thing that should be STATE-dependent;
STATE is the state of the text interpreter, nothing else.
Of course there are some ideas to get rid of STATE completely; many of
them just replace one kludge (STATE) with a different kludge, but at
least one doesn't: you could prefix every word with a character saying
whether you want to execute it now, compile it, or postpone it
(similar to colorForth). Disadvantage: You would have to change all
the prefixes when cutting and pasting code from within colon
definitions to the outside or vice versa.
>Elsehwere in this thread, you said:
>
>> 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.
>
>If you're going to excise STATE-smart words, shouldn't this be
>consistent, i.e., done everywhere?
A STATE-dependent FIND is certainly something that can be avoided,
simply by replacing FIND with something better. E.g., the fragment of
the user-defined text interpreter above could be replaced with:
... ( c-addr u )
find-name ?dup if
state @ if
name>compile
else
name>interpret
then
execute
else
( whatever you do for an undefined word )
then
>I.e., if you can't actually
>eliminate the use of the word STATE everywhere, what is the point
>of attempting to do so, in part?
The words that do not use STATE can be used in any state (e.g., in
macros) without them starting to behave differently from the state
where you tested it. If everything except the text interpreter is
STATE-independent, you can use these words freely in, e.g., macros.
- 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-30 01:55 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <1f25d88d-bef9-4242-ba9c-798f95c17081@googlegroups.com> |
| In reply to | #40121 |
On Monday, 29 June 2015 23:06:25 UTC+1, Paul Rubin wrote:
> "Elizabeth D. Rather" <> writes:
> > It is an integer. According to Forth2012, "The true value in STATE is
> > non-zero, but is otherwise implementation-defined." So it can
> > certainly be, for example, the xt of a word to handle
> > compilation. FORTH, Inc. has used it this way for some years.
>
> Well, I was thinking in terms of user-written or otherwise hacky text
> interpreters. Example: say you use Forth 200x-style locals,
>
> : foo {: x y | z -- :} .... ;
>
> One way to compile this is to make {: a parsing word that reads tokens
> until it sees the :}. Another is use state, so that
>
> state = 0 => interpreter
> state = 1 => inside normal colon definition
> state = 2 => inside a {: ... :} but before the |
> state = 3 => inside a {: ... :} after the | but before the --
> state = 4 => inside a {: ... :} and after the --
>
> Then the semantics of individual words could switch on state. So {: in
> state 1 would set state to 2, after which any word with no special state
> 2 semantics would emit code to pop the data stack onto a locals stack,
> and generate a temporary dictionary entry that remembers how many locals
> items had been pushed. | would switch to state 3. Non-special names in
> state 3 would do the same as state 2, except they'd push a 0 on the
> locals stack instead of copying from the data stack. -- would set state
> to 4 and remember the total number of items pushed on the locals stack
> so that the variable could be found by indexing into it, and names in
> state 4 would do nothing. :} would go back to state 1.
>
> I don't know whether the above is better or worse than making {: into a
> parsing word, in terms of forthiness.
John Hayes used a similar technique way back in the days of black
and white. He used state as a counter to allow conditionals at the
command line. It's very simple, elegant code.
In my system, ffaihm tracks the first free address in high memory
(the memory map os split into two areas. Pain in the ass.
0x8320 is the XT on my system for DOCOL.
Here's my code, adapated from his (see attribution below)
--BLOCK-00034---------
variable _rp \ John R. Hayes, Forth Dimensions Vol 12 No.2
: ]] ( -- ) state @ 0= if ffailm @ dup _rp ! h ! $8320 , then
-1 state +! ;
: [[ ( -- ) 1 state +! state @ 0= if compile exit
_rp @ ffailm ! ffaihm @ h ! _rp @ execute then ;
variable lastState
: [ state @ lastState ! 0 state ! ; immediate
: ] lastState @ state ! ; immediate
: do ]] [compile] do ; immediate
: loop [compile] loop [[ ; immediate
: if ]] [compile] if ; immediate
: then [compile] then [[ ; immediate
: begin ]] [compile] begin ; immediate
: repeat [[ [compile] repeat ; immediate
: until [[ [compile] until ; immediate
cr .( Interactive control structures loaded.)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-01 20:32 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <cc83d69b-024f-4247-b964-3b9670f73aa7@googlegroups.com> |
| In reply to | #39997 |
On Tuesday, June 23, 2015 at 10:04:46 AM UTC-7, Anton Ertl wrote: > 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. As I pointed out previously, this is not ANS-Forth at all --- there is nothing in the ANS-Forth document to justify a state-smart FIND that returns different xt values for the same look-up string under different circumstances. Also, Anton is doing this backwards anyway. In MFX I had HOST code and TARG code. When the user compiled a definition in TARG mode, a second definition was meta-compiled automatically in HOST mode. The HOST mode version was an immediate word that compiled the TARG mode version. So, all ordinary colon words and CREATE words etc. that were written in TARG mode had a same-name version of themselves meta-compiled in HOST mode that compiled them when it was run. It was also possible for the user to hand-write HOST mode immediate words --- BEGIN IF semicolon, etc. were all hand-written HOST mode immediate words --- none of these had a version of themselves in TARG mode. Anton is doing it backwards in gForth. He has words like IF etc. having two versions of themselves representing "compilation semantics" and "interpretation semantics" --- but ordinary colon words and CREATE words etc., have only one version. This is completely backwards! It is meaningless for a word like IF to have a TARG mode version. In my system, IF compiled a 0BRANCH --- but this doesn't mean that 0BRANCH is the "compilation semantics" version of IF --- 0BRANCH is just some TARG mode code that IF compiles, but it doesn't exactly represent IF because IF doesn't just compile 0BRANCH but does some other things as well (such as leave the address of the 0BRANCH operand on the control-flow stack for ELSE or THEN). gForth is not compliant with ANS-Forth. gForth is not compliant with common-sense either. I think Anton Ertl may have seen a cross-compiler at some time in the past, but he didn't understand how it worked. He didn't understand that FIND is not STATE-smart, but rather than FIND looks up words using the search-order at the time, which may be different inside a colon word as compared to outside a colon word. He also didn't understand that only the ordinary colon words and CREATE words etc. have two versions of themselves, but the hand-written immediate words such as IF etc. only have a HOST mode version. Anton Ertl is groping in the dark, doing experimental programming, trying to figure out how compilation works. This is not really a bad thing. At one time I was also groping in the dark, doing experimental programming, trying to figure out how compilation works --- that was in the early 1990s before I wrote MFX --- everybody has to learn this way. I think that it is a bad thing however, for Anton Ertl to be the chair-person of the Forth-200x committee. Writing a standards document is not really the best way to learn. I would feel a lot better about gForth if Anton Ertl said: "Here is an experimental Forth with some new ideas I'm trying out." This is instead of saying that gForth is the canonical ANS-Forth system, and any ANS-Forth program that fails to work under gForth is necessarily broken (such as my program back in 2009 where I committed the awful sin of ticking semicolon and was consequently denounced for not knowing ANS-Forth). Anton Ertl's excuse for the screw-ball ANS-Forth standard is that the ANS-Forth committee was trying to allow cmForth to be ANS-Forth compliant. Most likely, none of the committee members understood how cmForth worked, or understood how cross-compilation worked either. The irony here is that I have never seen any evidence to indicate that Charles Moore asked to have cmForth be ANS-Forth compliant. Jeff Fox told me that Charles Moore had said that ANS-Forth was 100 times more complicated than necessary --- this doesn't sound like an endorsement --- I think the ANS-Forth committee was trying to attract Charles Moore to ANS-Forth by telling him that his cmForth could be ANS-Forth compliant too, but he just ignored them (because they didn't understand how cmForth worked and they had nothing to contribute). The ANS-Forth document is full of ambiguous statements about how something may behave in one way or may behave in another way (section 3.2.3.2, for example) --- a lot of this wishy-washy ambiguity comes from the fact that the ANS-Forth committee was trying to get as many Forth systems as possible under the ANS-Forth umbrella by telling them all that they could be ANS-Forth too --- and nevermind the fact that they were not compatible with each other, and in many cases were in out-right contradiction to each other. ANS-Forth is completely broken. Anton Ertl argues at length (since 2009) that it is legal in ANS-Forth for FIND and/or tick to abort when given certain words (such as IF and semicolon, etc.) --- he is trying to prove that he is an expert in ANS-Forth --- but all that he succeeds in doing is proving that ANS-Forth is completely broken (the typical result of putting a sales-person in charge of writing a language standard).
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-07-02 02:40 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <b8575a81-c926-4918-ac14-c6da8b2cd928@googlegroups.com> |
| In reply to | #40226 |
On Thursday, 2 July 2015 04:32:57 UTC+1, hughag...@gmail.com wrote: The ANS-Forth document is full of ambiguous statements about how something may behave in one way or may behave in another way (section 3.2.3.2, for example) --- a lot of this wishy-washy ambiguity comes from the fact that the ANS-Forth committee was trying to get as many Forth systems as possible under the ANS-Forth umbrella by telling them all that they could be ANS-Forth too --- and nevermind the fact that they were not compatible with each other, and in many cases were in out-right contradiction to each other. I'm inclined to agree. Such broadness in standard smacks of politically motivated concessions, and is contrary to the central tenet of the standard; that being: To promote portability. On the positive side, the *reality* is that there are relatively few areas that cause major portability problems - but some of them are howlers. XTs and semantics being the biggest issues IMO.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-07-02 22:40 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <9a8f5c92-4961-4e9e-a706-a1ebcb026bc0@googlegroups.com> |
| In reply to | #40238 |
On Thursday, July 2, 2015 at 2:40:39 AM UTC-7, Mark Wills wrote: > On Thursday, 2 July 2015 04:32:57 UTC+1, hughag...@gmail.com wrote: > The ANS-Forth document is full of ambiguous statements about how something may behave in one way or may behave in another way (section 3.2.3.2, for example) --- a lot of this wishy-washy ambiguity comes from the fact that the ANS-Forth committee was trying to get as many Forth systems as possible under the ANS-Forth umbrella by telling them all that they could be ANS-Forth too --- and nevermind the fact that they were not compatible with each other, and in many cases were in out-right contradiction to each other. > > I'm inclined to agree. Such broadness in standard smacks of politically > motivated concessions, and is contrary to the central tenet of the > standard; that being: To promote portability. That is what I mean when I say that ANS-Forth is the result of putting a salesperson in charge of a language standard --- it is all about politics with little or no concern for technical issues --- the committee didn't care about the ambiguity because they knew that ultimately ANS-Forth compliance is granted by Elizabeth Rather (like a fairy queen who taps you on the head with her magic wand), and it really has nothing to do with technical compliance. A good example is gForth with its bizarre STATE-smart FIND that is clearly not ANS-Forth compliant, yet gForth is granted ANS-Forth compliance by fiat. I think that gForth was purposely crippled by being written in C so that it would be slower than SwiftForth --- Anton Ertl did this in exchange for Elizabeth Rather making him the Forth-200x chair-person --- he wouldn't have gotten the job if he had made gForth competitive. > On the positive side, the *reality* is that there are relatively > few areas that cause major portability problems - but some of them > are howlers. XTs and semantics being the biggest issues IMO. Portability of ANS-Forth only works so long as people stick to super-novice level programming such as was taught in "Starting Forth" --- as soon as anybody moves ahead into intermediate-level or advanced-level programming, the portability crumbles like a house of cards. My first-ever ANS-Forth program was the LowDraw.4th program, and it worked without problem. My second ANS-Forth program was the LC53 encryption-cracking program, and it was problematic --- I ticked semicolon (gasp!) and the house of cards collapsed --- tick and FIND are actually novice-level Forth, so I hadn't even progressed to intermediate-level Forth yet at the time that I encountered one of ANS-Forth's many pit-falls. https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B176-200%5D
[toc] | [prev] | [next] | [standalone]
Page 12 of 26 — ← Prev page 1 … 10 11 [12] 13 14 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web