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 5 of 26 — ← Prev page 1 … 3 4 [5] 6 7 … 26 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-18 23:58 -0700 |
| Message-ID | <cfad31de-3a3c-4e95-91ec-9913de579fcf@googlegroups.com> |
| In reply to | #39840 |
> > If you take out all ambiguities what does remain? How much of it? I > > said there are TOO MANY ambiguities. > > Section "4.1.2 Ambiguous conditions" covers them all. Which ones would > you make unambiguous? > TOO MANY. I don't have the time here to fix the standard. I also don't trust you that you really want this answer from me. I also don't believe that anybody that could really have the power to modify the standard will ever listen to me. Stephen Pelc said that clearly. > > > > >> > > >> >> Personally I think that ANS was born just to be an umbrella for some forths > >> >> at that time. > >> >> Those forths had a lot of incompatibilities so the ANS was forced > >> >> to "accomodate" these incompatibilities as "ambiguous conditions". > >> > > >> > I agree. And we're still living with the effects. > >> > > >> > >> As someone that does standards for a living (elsewhere, not here) I'm > >> fascinated by the assertion that a standard that doesn't require specific > >> effects on all inputs is considered in some way flawed. If there's one > > > > It was about FIND (or tick). There are not too many inputs. In fact > > there is only one input: the word. Do you find it? Or don't you? The > > word type or how many types can we have, it's another discussion. > > Let's have that discussion. > > We have positive integers, unsigned numbers, negative numbers, zero and > so on. There are limits to numbers; varying cells sizes make max and mins > vary from system to system. 123456789 123456789 * is a valid number, but > it is far too large for my system to represent accurately. Numbers have > ambiguities. > > The same is true of words. There are groups of words, and one of them -- > those with no interpretation semantics -- results in an ambiguous > condition and it's up to each system what to do. > Still one input: word or not a word? Numbers are not words. Return "not found" for numbers. Words are words. If you found it, return its xt. Full stop. It's not the function of tick to check if the words can be executed or not in interpretation mode or any other mode. Tick should find something and return an xt, EXECUTE is for executing. > > > >> thing that standards folks try not to do, it's bind the hands of > >> implementors or disqualify systems by being over prescriptive. We also > >> try to ensure that users (those the implementors wish to sell to) can > >> take what they have, and with little or no changes, use our systems. > >> > >> An example of that is Hugh's insistence that the control flow stack > >> should be a separate stack. It's explicitly mentioned in the standard > >> that the control flow stack might be the data stack. Generations of Forth > >> programmers have managed to write portable Forth with this ambiguity. > >> Systems can choose to implement the control flow stack in a multiplicity > >> of ways. > >> > > The control stack being data stack is really obsolete. It's so simple > > to have a separate stack for control flow, even for the most > > constrained embedded systems! I would see this another way: starting > > with '90 (for example) the modern forth systems should have been > > trying to insists on separate control flow stack. Now we would have > > been able to call this an obsolete feature and take away another "may > > or may not" from the 20xy standard. > > At compile time we would require 3 stacks. Why is this needed? > Asking again and again questions which was responded a lot of times before don't help a discussion. You probably don't need 3 stacks. A good standard will force you to implement 3 stacks. If you feel this too hard, give away being standard. Standards are not for everybody. > > > >> Yes, sometimes a standard gets it wrong. Then it's up to the standards > >> group *to accomodate existing practise* where possible, and without > >> requiring major re-engineering work. But there has to be evidence that > >> there is a problem caused by the lack of (or incorrect) specification. > >> > >> Why would you want it otherwise? > > > > I would want it said clearly in the next standard (that tick find etc > > to return an xt) and the "major forth vendors" (including open source > > ones) to fix their implementation. Is this requiring major > > re-engineering work? I don't think so. > > > > What would you do with this conformity? In particular, what would you > have ' IF do when executed? > Are you going to ask this kind of question to any programmer trying to use a word? It's about ' (tick). I want it to give me the xt of the word not to abort in my face. Simple as that. It's my problem what I do with the word ticked. > >
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-19 08:23 +0100 |
| Message-ID | <mm0fv1$vt3$1@dont-email.me> |
| In reply to | #39848 |
on 19/06/2015 07:58:39, Raimond Dragomir wrote: >> > If you take out all ambiguities what does remain? How much of it? I >> > said there are TOO MANY ambiguities. >> >> Section "4.1.2 Ambiguous conditions" covers them all. Which ones would >> you make unambiguous? >> > TOO MANY. I don't have the time here to fix the standard. I also don't > trust you that you really want this answer from me. I also don't > believe that anybody that could really have the power to modify the > standard will ever listen to me. Stephen Pelc said that clearly. > In other words, you want to shout and yell and jump up and down but not do anything because no-one ever listens to you. >> >> > >> >> > >> >> >> Personally I think that ANS was born just to be an umbrella for some forths >> >> >> at that time. >> >> >> Those forths had a lot of incompatibilities so the ANS was forced >> >> >> to "accomodate" these incompatibilities as "ambiguous conditions". >> >> > >> >> > I agree. And we're still living with the effects. >> >> > >> >> >> >> As someone that does standards for a living (elsewhere, not here) I'm >> >> fascinated by the assertion that a standard that doesn't require specific >> >> effects on all inputs is considered in some way flawed. If there's one >> > >> > It was about FIND (or tick). There are not too many inputs. In fact >> > there is only one input: the word. Do you find it? Or don't you? The >> > word type or how many types can we have, it's another discussion. >> >> Let's have that discussion. >> >> We have positive integers, unsigned numbers, negative numbers, zero and >> so on. There are limits to numbers; varying cells sizes make max and mins >> vary from system to system. 123456789 123456789 * is a valid number, but >> it is far too large for my system to represent accurately. Numbers have >> ambiguities. >> >> The same is true of words. There are groups of words, and one of them -- >> those with no interpretation semantics -- results in an ambiguous >> condition and it's up to each system what to do. >> > Still one input: word or not a word? Numbers are not words. Return > "not found" for numbers. Words are words. If you found it, return its > xt. Full stop. It's not the function of tick to check if the words can > be executed or not in interpretation mode or any other mode. Tick > should find something and return an xt, EXECUTE is for executing. I'll repeat my question. What should the xt that ' IF returns do? > >> > >> >> thing that standards folks try not to do, it's bind the hands of >> >> implementors or disqualify systems by being over prescriptive. We also >> >> try to ensure that users (those the implementors wish to sell to) can >> >> take what they have, and with little or no changes, use our systems. >> >> >> >> An example of that is Hugh's insistence that the control flow stack >> >> should be a separate stack. It's explicitly mentioned in the standard >> >> that the control flow stack might be the data stack. Generations of Forth >> >> programmers have managed to write portable Forth with this ambiguity. >> >> Systems can choose to implement the control flow stack in a multiplicity >> >> of ways. >> >> >> > The control stack being data stack is really obsolete. It's so simple >> > to have a separate stack for control flow, even for the most >> > constrained embedded systems! I would see this another way: starting >> > with '90 (for example) the modern forth systems should have been >> > trying to insists on separate control flow stack. Now we would have >> > been able to call this an obsolete feature and take away another "may >> > or may not" from the 20xy standard. >> >> At compile time we would require 3 stacks. Why is this needed? >> > Asking again and again questions which was responded a lot of times > before don't help a discussion. I'm asking you, not other people who have thought about it and responded elsewhere. > You probably don't need 3 stacks. A good standard will force you to > implement 3 stacks. If you feel this too hard, give away being > standard. Standards are not for everybody. That's almost funny. > >> > >> >> Yes, sometimes a standard gets it wrong. Then it's up to the standards >> >> group *to accomodate existing practise* where possible, and without >> >> requiring major re-engineering work. But there has to be evidence that >> >> there is a problem caused by the lack of (or incorrect) specification. >> >> >> >> Why would you want it otherwise? >> > >> > I would want it said clearly in the next standard (that tick find etc >> > to return an xt) and the "major forth vendors" (including open source >> > ones) to fix their implementation. Is this requiring major >> > re-engineering work? I don't think so. >> > >> >> What would you do with this conformity? In particular, what would you >> have ' IF do when executed? >> > Are you going to ask this kind of question to any programmer trying to > use a word? It's about ' (tick). I want it to give me the xt of the > word not to abort in my face. Simple as that. It's my problem what I > do with the word ticked. > There are two things you can do wih an xt. COMPILE, it or EXECUTE it. What would you have ' IF COMPILE, do when executed, or ' IF EXECUTE do?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-19 01:01 -0700 |
| Message-ID | <c588e444-6e45-48d6-883c-f0076f5560ee@googlegroups.com> |
| In reply to | #39850 |
On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: > > I'll repeat my question. What should the xt that ' IF returns do? > It shouldn't do anything, Alex; it's an XT, a token that represents some executable code. I'm being slightly facetious, but only slightly. The point is, ' doesn't know what I want to do with that XT. How dare it presume that I want to execute it, and that executing it in a particular state is illegal. Perhaps I don't want to execute it at all. Perhaps I want to do this, as I can in my system: ' IF >LINK 10 DUMP Allowing me to see the dictionary entry, it's linkage info, flags etc.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Östreicher <thomas.oestreicher@gmail.com> |
|---|---|
| Date | 2015-06-19 01:07 -0700 |
| Message-ID | <04d4c360-d274-41a0-8b75-9e8394945599@googlegroups.com> |
| In reply to | #39856 |
On Friday, 19 June 2015 10:01:26 UTC+2, Mark Wills wrote: > On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: > > > > I'll repeat my question. What should the xt that ' IF returns do? > > > It shouldn't do anything, Alex; it's an XT, a token that represents > some executable code. I'm being slightly facetious, but only slightly. > The point is, ' doesn't know what I want to do with that XT. How > dare it presume that I want to execute it, and that executing it > in a particular state is illegal. Perhaps I don't want to execute > it at all. Perhaps I want to do this, as I can in my system: > > ' IF >LINK 10 DUMP > > Allowing me to see the dictionary entry, it's linkage info, flags etc. Maybe I am wrong here, but isn't this what name tokens in forth200x are for?
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-19 09:38 +0000 |
| Message-ID | <5583e243.67171534@news.eternal-september.org> |
| In reply to | #39856 |
On Fri, 19 Jun 2015 01:01:25 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: >On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: >> >> I'll repeat my question. What should the xt that ' IF returns do? >> >It shouldn't do anything, Alex; it's an XT, a token that represents >some executable code. I'm being slightly facetious, but only slightly. >The point is, ' doesn't know what I want to do with that XT. How >dare it presume that I want to execute it, and that executing it >in a particular state is illegal. Perhaps I don't want to execute >it at all. Perhaps I want to do this, as I can in my system: > >' IF >LINK 10 DUMP > >Allowing me to see the dictionary entry, it's linkage info, flags etc. An excellent example. In my opinion, a word with a name should have an xt. The xt is the token for access to all the other parts of the word, including those parts that the standard does not describe. That EXECUTE or COMPILE, give silly results when applied to a specific xt does not remove the utility of the xt for that word. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-19 02:51 -0700 |
| Message-ID | <10c0e92d-cdfa-4cf9-bcf4-7e19785a09e1@googlegroups.com> |
| In reply to | #39860 |
On Friday, 19 June 2015 10:38:53 UTC+1, Stephen Pelc wrote: > On Fri, 19 Jun 2015 01:01:25 -0700 (PDT), Mark Wills > <markwills1970@gmail.com> wrote: > > >On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: > >> > >> I'll repeat my question. What should the xt that ' IF returns do? > >> > >It shouldn't do anything, Alex; it's an XT, a token that represents > >some executable code. I'm being slightly facetious, but only slightly. > >The point is, ' doesn't know what I want to do with that XT. How > >dare it presume that I want to execute it, and that executing it > >in a particular state is illegal. Perhaps I don't want to execute > >it at all. Perhaps I want to do this, as I can in my system: > > > >' IF >LINK 10 DUMP > > > >Allowing me to see the dictionary entry, it's linkage info, flags etc. > > An excellent example. > > In my opinion, a word with a name should have an xt. The xt is > the token for access to all the other parts of the word, including > those parts that the standard does not describe. That EXECUTE or > COMPILE, give silly results when applied to a specific xt does > not remove the utility of the xt for that word. > > Stephen Agree.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-20 16:35 +0000 |
| Message-ID | <2015Jun20.183512@mips.complang.tuwien.ac.at> |
| In reply to | #39860 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Fri, 19 Jun 2015 01:01:25 -0700 (PDT), Mark Wills
><markwills1970@gmail.com> wrote:
>>Perhaps I want to do this, as I can in my system:
>>
>>' IF >LINK 10 DUMP
>>
>>Allowing me to see the dictionary entry, it's linkage info, flags etc.
>
>An excellent example.
>
>In my opinion, a word with a name should have an xt.
Or maybe two, as described in the standard for the result of FIND.
>The xt is
>the token for access to all the other parts of the word, including
>those parts that the standard does not describe.
Somehow I find it strange that you have claimed in earlier times that
the non-standardization of words like >LINK was a great achievement of
Forth-94 (and interpret a one-token-to-rule-them-all role for the xt
into that), and now you applaud Mark Will's use of >LINK. Have you
changed your position, or is this an exercise in doublethink?
- 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-20 21:28 -0700 |
| Message-ID | <9b41f6ee-1871-48b7-bc9a-1778c42deccb@googlegroups.com> |
| In reply to | #39894 |
A nice attempt to swerve the argument away from tick. You know very well Stephen was referring to tick, not >LINK. ' is the only way to get access to the word in interpretation mode. Who cares if it has "interpretation semantics" or not? Maybe I don't want to interpret it. My example using DUMP is an example of that. If I'm correct, Gforth can't do that. And that is pathetic.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-20 21:33 -0700 |
| Message-ID | <9e152f45-1e18-41f1-9f23-cbcd352eda8a@googlegroups.com> |
| In reply to | #39914 |
On Saturday, June 20, 2015 at 9:28:22 PM UTC-7, Mark Wills wrote: > A nice attempt to swerve the argument away from tick. You know very well Stephen was referring to tick, not >LINK. > > ' is the only way to get access to the word in interpretation mode. Who cares if it has "interpretation semantics" or not? Maybe I don't want to interpret it. My example using DUMP is an example of that. If I'm correct, Gforth can't do that. And that is pathetic. Which post are you responding to?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-20 21:49 -0700 |
| Message-ID | <6d30b58f-ccbb-4cf7-bd5d-169542833f36@googlegroups.com> |
| In reply to | #39915 |
Sorry. I was responding to Anton's last post. It seems Gmail via mobile phone doesn't quote the posts.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-21 14:01 +0000 |
| Message-ID | <2015Jun21.160132@mips.complang.tuwien.ac.at> |
| In reply to | #39914 |
Mark Wills <markwills1970@gmail.com> writes:
>A nice attempt to swerve the argument away from tick. You know very well St=
>ephen was referring to tick, not >LINK.
No, he called your example, including ">LINK", excellent. And he
explicitly wrote about "access to other parts of the word".
>' is the only way to get access to the word in interpretation mode.
:noname c" if" ; execute find drop
Also an ambiguous condition, i.e., also non-standard; and the
following are non-standard from using non-standard words:
s" if" find-name name>int
comp' if drop
The latter produces an xt for the compilation semantics of IF, which
is more likely what the user wanted to get.
> Who car=
>es if it has "interpretation semantics" or not? Maybe I don't want to inter=
>pret it.
Why use "'", if you don't want interpretation semantics?
>My example using DUMP is an example of that. If I'm correct, Gfort=
>h can't do that.
In Gforth 0.7:
:noname c" if" ; execute find drop >name 32 dump
7FFFF69F4AD8: 70 4A 9F F6 FF 7F 00 00 - 12 00 00 00 00 00 00 80 pJ..............
7FFFF69F4AE8: 63 6F 6D 70 69 6C 65 2D - 6F 6E 6C 79 2D 65 72 72 compile-only-err
ok
s" if" find-name 32 dump
7FFFF6A01F00: 90 1E A0 F6 FF 7F 00 00 - 02 00 00 00 00 00 00 E0 ................
7FFFF6A01F10: 49 46 20 20 20 20 20 20 - E5 43 40 00 00 00 00 00 IF .C@.....
ok
comp' if drop >name 32 dump
7FFFF6A01F00: 90 1E A0 F6 FF 7F 00 00 - 02 00 00 00 00 00 00 E0 ................
7FFFF6A01F10: 49 46 20 20 20 20 20 20 - E5 43 40 00 00 00 00 00 IF .C@.....
ok
- 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-21 14:19 +0000 |
| Message-ID | <5586c4e9.256267662@news.eternal-september.org> |
| In reply to | #39894 |
On Sat, 20 Jun 2015 16:35:12 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>In my opinion, a word with a name should have an xt. > >Or maybe two, as described in the standard for the result of FIND. No. The concession to cmForth in ANS can now be seen as a mistake. An xt is (or should be) the token from which all else about a word can be derived. A further lesson is that there may still be other mistakes in the standard. It is more productive to assume that there are mistakes in the standard and to be prepared to change them over time. >>The xt is >>the token for access to all the other parts of the word, including >>those parts that the standard does not describe. > >Somehow I find it strange that you have claimed in earlier times that >the non-standardization of words like >LINK was a great achievement of >Forth-94 (and interpret a one-token-to-rule-them-all role for the xt >into that), and now you applaud Mark Will's use of >LINK. Have you >changed your position, or is this an exercise in doublethink? I applauded his example, not a specific word in that example. No change of position, no doublethink. Just a recognition that parts of a Forth system may not be portable. Just consider the word >LINK again. What's at that address? We have seen both absolute and relative links in the past. It is not sensible for a standard to define the implementation. If a system chooses to expose >LINK that's its business, but the standard has no business mandating or preferring one dictionary implementation over another. There's actually nothing wrong with having to write some code that is implementation dependent. The issue is in the documentation and specification of it. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-22 13:16 +0000 |
| Message-ID | <2015Jun22.151615@mips.complang.tuwien.ac.at> |
| In reply to | #39929 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 20 Jun 2015 16:35:12 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>In my opinion, a word with a name should have an xt.
>>
>>Or maybe two, as described in the standard for the result of FIND.
>
>No. The concession to cmForth in ANS can now be seen as a mistake.
>An xt is (or should be) the token from which all else about a word
>can be derived.
No. As long as we have words with non-default and non-immediate
compilation semantics (such as S" and TO), the way to go is to
1) have xt0, an xt representing the interpretation semantics
2) have a compilation token representing the compilation semantics,
consisting of xt1 xt2, where xt1 is xt0 for normal and immediate
words, and some other xt for S"-like words; and xt2 is the xt of
EXECUTE or COMPILE,.
Deriving everything else from the xt0 and xt1 is not a problem of
principle but one of implementation cost and usefulness. Sure it is
possible to implement things in a way that allows us to, e.g., get all
the nts of named words that have the passed xt as xt0, or as xt1, but
will any system implementor do it?
>A further lesson is that there may still be other mistakes in the
>standard. It is more productive to assume that there are mistakes
>in the standard and to be prepared to change them over time.
I think the major mistake in this area is words like S". We should
get rid of them.
>Just a recognition that parts
>of a Forth system may not be portable. Just consider the word >LINK
>again. What's at that address? We have seen both absolute and relative
>links in the past. It is not sensible for a standard to define the
>implementation. If a system chooses to expose >LINK that's its
>business, but the standard has no business mandating or preferring one
>dictionary implementation over another.
Like one where all else about a word can be derived from the xt?
- 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-22 16:53 +0000 |
| Message-ID | <55883c10.352306620@news.eternal-september.org> |
| In reply to | #39962 |
On Mon, 22 Jun 2015 13:16:15 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>No. The concession to cmForth in ANS can now be seen as a mistake. >>An xt is (or should be) the token from which all else about a word >>can be derived. > >No. As long as we have words with non-default and non-immediate >compilation semantics (such as S" and TO), the way to go is to > >1) have xt0, an xt representing the interpretation semantics > >2) have a compilation token representing the compilation semantics, >consisting of xt1 xt2, where xt1 is xt0 for normal and immediate >words, and some other xt for S"-like words; and xt2 is the xt of >EXECUTE or COMPILE,. > >Deriving everything else from the xt0 and xt1 is not a problem of >principle but one of implementation cost and usefulness. Sure it is >possible to implement things in a way that allows us to, e.g., get all >the nts of named words that have the passed xt as xt0, or as xt1, but >will any system implementor do it? Now you have exposed xt0, xt1, xt2 and we need an nt too! These are tokens from one implementation, not from common practice. All this is "stuff" that an xt was designed to avoid. If you want to rename xt to wt (word token), be my guest. Your four tokens are part of the implementation. They can all be obtained from the xt/wt. >I think the major mistake in this area is words like S". We should >get rid of them. We're lumbered with them for the next twenty years or so. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-23 15:39 +0000 |
| Message-ID | <2015Jun23.173949@mips.complang.tuwien.ac.at> |
| In reply to | #39969 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Mon, 22 Jun 2015 13:16:15 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>No. The concession to cmForth in ANS can now be seen as a mistake.
>>>An xt is (or should be) the token from which all else about a word
>>>can be derived.
>>
>>No. As long as we have words with non-default and non-immediate
>>compilation semantics (such as S" and TO), the way to go is to
>>
>>1) have xt0, an xt representing the interpretation semantics
>>
>>2) have a compilation token representing the compilation semantics,
>>consisting of xt1 xt2, where xt1 is xt0 for normal and immediate
>>words, and some other xt for S"-like words; and xt2 is the xt of
>>EXECUTE or COMPILE,.
>>
>>Deriving everything else from the xt0 and xt1 is not a problem of
>>principle but one of implementation cost and usefulness. Sure it is
>>possible to implement things in a way that allows us to, e.g., get all
>>the nts of named words that have the passed xt as xt0, or as xt1, but
>>will any system implementor do it?
>
>Now you have exposed xt0, xt1, xt2 and we need an nt too! These are
>tokens from one implementation, not from common practice.
They are even standardized:
FIND arguably returns xt0 in interpret state and xt1 in compile state,
and it returns a flag that corresponds to xt2 (when the flag is -1,
xt2 is the xt of COMPILE, and when the flag is 1, xt2 is the xt of
EXECUTE).
NAME>INTERPRET returns xt0
NAME>COMPILE returns xt1 xt2
In many systems xt0=xt1, but if you want to be able to tick S" and TO
(which is not guaranteed by the standard, but which you advocate) and
if the resulting execution token should behave as standard execution
tokens behave, then for these words xt0 must be different from xt1.
>All this is "stuff" that an xt was designed to avoid. If you want to
>rename xt to wt (word token), be my guest. Your four tokens are part
>of the implementation. They can all be obtained from the xt/wt.
I don't care about the name of the token; what I do care about is that
COMPILE, works properly.
Concerning whether xt0 (or xt1) also serves as nt or, in general as
the key to all the stuff concerning the word, that's fine with me, but
I expect that some implementors won't like this requirement. It
restricts system implementations, and I don't see a significant
advantage to programmers. But if you convince the other system
implementors, I certainly won't object.
>>I think the major mistake in this area is words like S". We should
>>get rid of them.
>
>We're lumbered with them for the next twenty years or so.
Sure it will take a long time to get rid of them completely, but we
could start by putting the replacement in place and declaring them to
be obsolescent in the near future, and then they will play the same
role that, say, SPAN has played in the last 20 years.
- 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-23 18:11 +0000 |
| Message-ID | <55899e7b.443037660@news.eternal-september.org> |
| In reply to | #39994 |
On Tue, 23 Jun 2015 15:39:49 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>Now you have exposed xt0, xt1, xt2 and we need an nt too! These are >>tokens from one implementation, not from common practice. > >They are even standardized: Standardised in 2012 perhaps, but we were wrong! Before we go ahead with further mission creep, we should actually define what we are trying to achieve in the kernel. For example, maintenance of conceptual simplicity is one objective that I favour. If we cannot work out how to live with a single xt, then we need to go back to the drawing board. We also need to preserve the classical Forth interpreter loop (after deciding about IMMEDIATE). I should have followed my instinct and voted no to a number of late proposals for Forth 2012. >In many systems xt0=xt1, but if you want to be able to tick S" and TO >(which is not guaranteed by the standard, but which you advocate) and >if the resulting execution token should behave as standard execution >tokens behave, then for these words xt0 must be different from xt1. I have never said that the xts returned by ticking S" or TO should be useful for much, only that they must exist. Once we have a set of objectives and a roadmap to these objectives, then we can decide where our targets lie. >Sure it will take a long time to get rid of them completely, but we >could start by putting the replacement in place and declaring them to >be obsolescent in the near future, and then they will play the same >role that, say, SPAN has played in the last 20 years. There is (IMHO) no replacement for S" in common use. If *you* want to get rid of S" then *you* have to say why and make proposals. Just saying that visible objectors are wrong is inadequate for these purposes. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-23 22:16 +0200 |
| Message-ID | <mmcenm$b66$1@dont-email.me> |
| In reply to | #39999 |
Stephen Pelc wrote: > I should have followed my instinct and voted no to a number of late > proposals for Forth 2012. Probably to the TRAVERSE-WORDLIST proposal which introduces the nt and conversions to nt -> xt0 (NAME>INTERPRET), and nt -> xt1 xt2 (NAME>COMPILE). On the other hand, the restrictions we have for a standard program now make both your system and Gforth standard; without adding restrictions like "you can't tike S"", Gforth would be standard, VFX wouldn't. There's however always the difference between allowing a particular implementation and mandading it. Forth-94, while not being explicit, did de facto mandate the dual-xt implementation of Gforth, but Forth-2012 doesn't. On the other hand, through the words in the TRAVERSE-WORDLIST proposal, the dual-xt concept gets more credit than it maybe deserves. Note that dual-wordlist Forths like cmForth are excluded from this approach; it doesn't work there. > I have never said that the xts returned by ticking S" or TO should be > useful for much, only that they must exist. > > Once we have a set of objectives and a roadmap to these objectives, > then we can decide where our targets lie. If I got you right, your agenda includes: * make xt a single point of reference, so that the xt allows straight- forward access to the definition's original name, and to the interpretation and compilation semantics * structural simplicity - fewer concepts are better than more. * regard structural complexity of the current and 94 standards as bugs, not as features; as accidential bugs coming from trying to make too many conflicting implementations standard. "back to the drawing board" also means that some incompatibility is accepted. Your VFX scheme contains the following essential components: ' <name> -> xt (single one) xt EXEUCTE -> interpretation semantics xt COMPILE, -> compilation semantics xt1 SET-COMPILER -> set compilation semantics of last definition to xt1, stack effect will be ( xt -- ), where xt is the execution token of that last definition. Applicale for CREATE .. DOES> words. ' EXECUTE SET-COMPILER -> sets compilation semantics = interpretation semantics The legacy way of defining compiler macros, as competition, has: ' <name> -> xt (single one) xt EXECUTE -> interpretation semantics, needs to be in interpretation state xt COMPILE, -> append interpretation semantics, called word must be in interpretation state C" <name>" FIND 0> IF EXECUTE ELSE COMPILE, THEN -> compilation semantics, needs to be in compilation state : <name> STATE @ IF .. ELSE .. THEN ; IMMEDIATE -> set special compilation semantics : <name> ... ; IMMEDIATE -> set compilation semantics = interpretation semantics (as such only useful for comment words and words like [IF]) Looks complicated and has a really awful global state Anton's dual-xt system has: ' <name> -> xt0 COMP' <name> -> xt1 xt2 xt0 EXECUTE -> interpretation semantics xt1 xt2 EXECUTE -> compilation semantics xt0 COMPILE, -> append interpretation semantics <name> FIND-NAME -> nt, new single point of reference not optimized for EXECUTE NAME>INTERPRET nt -> xt0 conversion for interpretation semantics NAME>COMPILE nt -> xt1 xt2 conversion for compilaton semantics INTERPRET/COMPILE: <name> xt0 xt1 -> create words with special compilation semantics, not applicable for CREATE DOES> words. : <name> ... ; IMMEDIATE -> set compilation semantics = interpretation semantics (as such only useful for comment words and words like [IF]) IMHO, VFX's system is the most elegant one. >>Sure it will take a long time to get rid of them completely, but we >>could start by putting the replacement in place and declaring them to >>be obsolescent in the near future, and then they will play the same >>role that, say, SPAN has played in the last 20 years. > > There is (IMHO) no replacement for S" in common use. If *you* want > to get rid of S" then *you* have to say why and make proposals. > Just saying that visible objectors are wrong is inadequate for > these purposes. Yes, recognizers which allow real string literals are certainly not yet common practice. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-23 23:26 +0000 |
| Message-ID | <5589e4e6.461064745@news.eternal-september.org> |
| In reply to | #40001 |
On Tue, 23 Jun 2015 22:16:07 +0200, Bernd Paysan <bernd.paysan@gmx.de> wrote: >Stephen Pelc wrote: >> I should have followed my instinct and voted no to a number of late >> proposals for Forth 2012. > >Probably to the TRAVERSE-WORDLIST proposal which introduces the nt and >conversions to nt -> xt0 (NAME>INTERPRET), and nt -> xt1 xt2 (NAME>COMPILE). In retrospect I should have voted no to that one. I do not object to the intent, but the idea behind nt has always disturbed me. >On the other hand, the restrictions we have for a standard program now make >both your system and Gforth standard; without adding restrictions like "you >can't tike S"", Gforth would be standard, VFX wouldn't. Where do we actually say that you can't tick S" ? >If I got you right, your agenda includes: > >* make xt a single point of reference, so that the xt allows straight- >forward access to the definition's original name, and to the interpretation >and compilation semantics > >* structural simplicity - fewer concepts are better than more. > >* regard structural complexity of the current and 94 standards as bugs, not >as features; as accidential bugs coming from trying to make too many >conflicting implementations standard. > >"back to the drawing board" also means that some incompatibility is >accepted. That's a good start. We also need to reduce the number of ambiguous conditions. We need to define properly how parsing words behave under all conditions. Each parsing word should be comprehensible without having to stick twenty post-it notes into the document. We need to rationalise ' ['] and FIND or FIND's replacement. The classical implementation of ' is something like: : ' \ "<spaces>name" -- xt bl word find ?undef ; such that the interpretation xt must be returned. With a classical ['] : ['] \ Comp: "<spaces>name" -- ; Run: -- xt ' postpone literal ; IMMEDIATE it's broken on a dual xt system. All of this comes under the heading of simplification. >>>Sure it will take a long time to get rid of them completely, but we >>>could start by putting the replacement in place and declaring them to >>>be obsolescent in the near future, and then they will play the same >>>role that, say, SPAN has played in the last 20 years. >> >> There is (IMHO) no replacement for S" in common use. If *you* want >> to get rid of S" then *you* have to say why and make proposals. >> Just saying that visible objectors are wrong is inadequate for >> these purposes. > >Yes, recognizers which allow real string literals are certainly not yet >common practice. Any volunteers to contribute one for VFX ? One could use the CUNDEFINED hook that is not documented ... Thank you, Bernd, for a post that I found really productive to my own thought-train. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-24 03:23 +0200 |
| Message-ID | <mmd0n5$6j7$1@dont-email.me> |
| In reply to | #40008 |
Stephen Pelc wrote: >>On the other hand, the restrictions we have for a standard program now >>make both your system and Gforth standard; without adding restrictions >>like "you can't tike S"", Gforth would be standard, VFX wouldn't. > > Where do we actually say that you can't tick S" ? I can't find it... TO, IS, and ACTION-OF all contain the necessary ambiguous conditions, and I'm pretty sure we discussed and voted to add that wording to S" and S\", too. All these parsing words with special compilation and interpretation semantics need that wording - no ticking, no POSTPONE and [COMPILE], because too many bad things can happen with the different implementations. Unless we make up our minds and have a well- defined unambiguous behavior for them. Seems to have gone lost in the editing process :-(. While one of the RFIs clarified that you can't tick compile-only words, we have not written that into the document, either. It's still implicit, and that's not a good idea. >>Yes, recognizers which allow real string literals are certainly not yet >>common practice. > > Any volunteers to contribute one for VFX ? One could use the > CUNDEFINED hook that is not documented ... No, that's the wrong hook. The recognizer stack completely replaces the outer interpreter, it's not just for undefined stuff. Therefore, this is much easier: the recognizer stack goes into the documented hook INTERPRET. Those people who use your CLASSHOOK might want to write a recognizer replacement for that hook. I'll try find some time doing it; it's fairly straight-forward. Something like : parser ( addr u -- .. xt ) do-recognizer state @ IF r>comp ELSE r>int THEN ; : (interpret) BEGIN ?stack parse-name dup WHILE parser execute REPEAT ; ' (interpret) is interpret on the top-level, the lower stuff needs just filling in of the details from already existing recognizer implementations. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-24 08:04 +0000 |
| Message-ID | <2015Jun24.100449@mips.complang.tuwien.ac.at> |
| In reply to | #40009 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Stephen Pelc wrote:
>>>On the other hand, the restrictions we have for a standard program now
>>>make both your system and Gforth standard; without adding restrictions
>>>like "you can't tike S"", Gforth would be standard, VFX wouldn't.
>>
>> Where do we actually say that you can't tick S" ?
>
>I can't find it... TO, IS, and ACTION-OF all contain the necessary
>ambiguous conditions, and I'm pretty sure we discussed and voted to add that
>wording to S" and S\", too.
Yes, I also have this memory. However, I don't find any trace of it
in my notes nor in the minutes. Maybe we have said so often that it
needs to be done that, at some point we though we had done it:-).
>All these parsing words with special
>compilation and interpretation semantics need that wording - no ticking, no
>POSTPONE and [COMPILE], because too many bad things can happen with the
>different implementations. Unless we make up our minds and have a well-
>defined unambiguous behavior for them.
Yes.
>While one of the RFIs clarified that you can't tick compile-only words, we
>have not written that into the document, either. It's still implicit, and
>that's not a good idea.
It's already in Forth-94, but not in the place where I (or apparently
you) normally look:
|4.1.2 Ambiguous conditions
|
|attempting to obtain the execution token, (e.g., with 6.1.0070 ',
|6.1.1550 FIND, etc. of a definition with undefined interpretation
|semantics;
>No, that's the wrong hook. The recognizer stack completely replaces the
>outer interpreter, it's not just for undefined stuff.
That's certainly one way to do it (more powerful and conceptually
simpler, no special case for the search order search), but I guess
there will be some discussions of whether we want this or less
powerful (and therefore more conservative) approach of just having the
recognizer stack replace the undefined-word stuff.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 5 of 26 — ← Prev page 1 … 3 4 [5] 6 7 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web