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 8 of 26 — ← Prev page 1 … 6 7 [8] 9 10 … 26 Next page →
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2015-06-19 10:55 +0300 |
| Message-ID | <mm0hr3$62s$1@dont-email.me> |
| In reply to | #39852 |
On 6/19/15 10:40, Mark Wills wrote: > On Thursday, 18 June 2015 21:31:09 UTC+1, Alex McDonald wrote: >> What would you do with this conformity? In particular, what would you >> have ' IF do when executed? Interesting question. In 8th, you can tick any word; whether that's necessarily useful or not depends on what you do afterwards. If you try to invoke 'exec' on the ticked 'if', you get an exception: "Exception: May only be used in compile mode..." That seems to me a reasonable thing to do, since 8th doesn't support interactive if statements.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-21 14:43 +0000 |
| Message-ID | <2015Jun21.164333@mips.complang.tuwien.ac.at> |
| In reply to | #39852 |
Mark Wills <markwills1970@gmail.com> writes:
>On Thursday, 18 June 2015 21:31:09 UTC+1, Alex McDonald wrote:
>> What would you do with this conformity? In particular, what would you
>> have ' IF do when executed?
>>
>I'd have it do what it does on my system: Execute the code that compiles
>a 0BRANCH sequence. Afterall, *maybe* that's exactly what I *intended*.
So you would have it perform the compilation semantics of IF, i.e., as
if the word was immediate and not compile-only. That's a pretty good
choice. Maybe we should get rid of words like S", and have all the
words with undefined interpretation semantics be either normal or
immediate, nothing else.
- 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-22 02:05 -0700 |
| Message-ID | <d20207c3-173a-4ddc-8a1a-1d9d3e594b6f@googlegroups.com> |
| In reply to | #39935 |
On Sunday, 21 June 2015 15:56:02 UTC+1, Anton Ertl wrote: > Mark Wills <markwills1970@gmail.com> writes: > >On Thursday, 18 June 2015 21:31:09 UTC+1, Alex McDonald wrote: > >> What would you do with this conformity? In particular, what would you > >> have ' IF do when executed? > >> > >I'd have it do what it does on my system: Execute the code that compiles > >a 0BRANCH sequence. Afterall, *maybe* that's exactly what I *intended*. > > So you would have it perform the compilation semantics of IF, i.e., as > if the word was immediate and not compile-only. I'm not able to discern if you are being sarcastic or not, but I'll take the bait. Yes. That's exactly what I would do. I fully appreciate that in the interpretation context it is meaningless - on my system (16-bit ITC) all it would do is compile some orhpaned code to memory - code that would never be executed. Thinking about it some more, I actually wouldn't object to IF doing a throw if executed in interpretation mode, since, as the standard says, the interpretation semantics of IF are undefined. I can see the reasoning behind that statement and have no issue with that per-se. To be clear, my issue is with tick or FIND and friends telling me what I can and can not obtain an xt for. I appreciate that we have POSTPONE for appending the compilation semantics of words and in 200x we have COMPILE, but they are only for compiling. We need a standardised way to differentiate between interpretation semantics and compilation semantics. We don't seem to have that. The clue is 200x in the text that accompanies COMPILE,: A.6.2.0945 COMPILE, COMPILE, is the compilation equivalent of EXECUTE. In traditional threaded-code implementations, compilation is performed by , (comma). This usage is not portable; it doesn't work for subroutine-threaded, native code, or relocatable implementations. Use of COMPILE, is portable. In most systems it is possible to implement COMPILE, so it will generate code that is optimized to the same extent as code that is generated by the normal compilation process. **However, in some implementations there are two different "tokens" corresponding to a particular definition name: the normal "execution token" that is used while interpreting or with EXECUTE, and another "compilation token" that is used while compiling.** ***It is not always possible to obtain the compilation token from the execution token. *** In these implementations, COMPILE, might not generate code that is as efficient as normally compiled code. So, the standard enshrines the concepts of interpretation and compilation semantics, but doesn't seem to give the programmer the tools to differentiate between the two behaviours. The crux of my argument is that everything should evolve around the XT, and the XT should be singular. Additional words could be standardised to provide access to the other behaviours; these words may produce a different XT. With this mechanism in place, tick still works like it always did. Tick does not need to nanny the programmer. ' if >interp ( -- ixt ) \ produce interpretation semantics of if ' if >comp ( -- cxt ) \ produce compilation semantics of if Now it might be that if has no interpretation semantics (since that's what the standard says) so the ixt might be the ixt of a throw routine that barfs and says "no interpretation semantics defined for this word". Thus this would produce an error: ' if >interp ( -- ixt) : my-if [ compile, ] ; immediate : test 1 2 > my-if ." greater" else ." less than" then ; If you ran test, it should say "no interpretation semantics defined for this word" because the dumb programmer explicitly asked for the interpretation semantics of IF - there are none, so what was returned was the XT of an error routine that does a throw at runtime, and you went right ahead and compiled it into your code. Programmers fault. Of course, in order to explicitly obtain the interpretation and runtime semantics of a word it must also be possible to set them. Stephen's SET-COMP is a step in the right direction in this regard. I think this this the crux of the problem: The standard enshrines the concept of interpretation and compilation sematics/behaviours, but there's no way to set them. We need to be able to do something like: : (if) ... ... compilation semantics of if ... ...; : (if-i) ERROR-CODE THROW ( no interpretation semantics) ; : my-if state @ if (if) else (if-i) then ; ' (if) ' if set-comp \ set compilation mode xt for set-comp and >comp ' (if-i) ' if set-int \ set interpretation mode xt for set-int and >int The above approach would enforce factoring because set-comp and set-int require XTs. >comp and >int return the same xts as were fed into set-comp and set-int. How my-if is physically associated with the two XTs is implementation defined, but would presumably be through fields in the header of the word. Now, ' ['] find et al can return a simple XT: ' my-if ...and it's up to me what I do with it thereafter: >comp compile, The default action of colon defintions would be to set the compilation and interpretation fields to the same address, unless they are explicitly overridden by set-comp and set-int: : 1to3 1 2 3 ; ' 1to3 >comp ' 1to3 >int = . -1 They're the same xt.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-22 16:41 +0000 |
| Message-ID | <2015Jun22.184111@mips.complang.tuwien.ac.at> |
| In reply to | #39952 |
Mark Wills <markwills1970@gmail.com> writes:
>On Sunday, 21 June 2015 15:56:02 UTC+1, Anton Ertl wrote:
>> Mark Wills <markwills1970@gmail.com> writes:
>> >On Thursday, 18 June 2015 21:31:09 UTC+1, Alex McDonald wrote:
>> >> What would you do with this conformity? In particular, what would you
>> >> have ' IF do when executed?
>> >>
>> >I'd have it do what it does on my system: Execute the code that compiles
>> >a 0BRANCH sequence. Afterall, *maybe* that's exactly what I *intended*.
>>
>> So you would have it perform the compilation semantics of IF, i.e., as
>> if the word was immediate and not compile-only.
>
>I'm not able to discern if you are being sarcastic or not, but I'll
>take the bait. Yes. That's exactly what I would do. I fully
>appreciate that in the interpretation context it is meaningless -
>on my system (16-bit ITC) all it would do is compile some orhpaned
>code to memory - code that would never be executed.
Whether it is executed depends on whether there is a surrounding
definition, not on whether the text intepreter is in interpret state.
E.g.,:
: foo [ ' if execute ] ." hello" then ;
true foo
false foo
If you allow ' IF, and the xt represents the compilation semantics,
then the code above should work.
>Thinking about it some more, I actually wouldn't object to IF doing
>a throw if executed in interpretation mode, since, as the standard
>says, the interpretation semantics of IF are undefined.
But that does not mean that the behaviour in interpret state is
undefined. Just that the text interpreter is not obligated to do
anything specific when it is in interpret state and encounters IF (and
that ' and ['] are not obligated, either). In particular, you can
define the interpretation semantics to be the same as the compilation
semantics as follows:
: if postpone endif ; immediate
Then this has to work:
: bar [ if ] ." hello" then ;
>I appreciate that we have POSTPONE for appending the compilation
>semantics of words and in 200x we have COMPILE, but they are only
>for compiling. We need a standardised way to differentiate between interpretation semantics and compilation semantics. We don't seem
>to have that.
I am not sure what you want to do with that way, but we have
Interpretation semantics:
', [']
text interpreter in interpretation state
FIND in interpretation state (arguable)
NAME>INTERPRET (Forth-2012)
Compilation semantics:
POSTPONE
text interpreter in compilation state
FIND in compilation state (arguable)
NAME>COMPILE (Forth-2012).
>The clue is 200x in the text that accompanies
>COMPILE,:
>
>A.6.2.0945 COMPILE,
>COMPILE, is the compilation equivalent of EXECUTE.
>In traditional threaded-code implementations, compilation is performed
>by , (comma). This usage is not portable; it doesn't work for
>subroutine-threaded, native code, or relocatable implementations.
>
>Use of COMPILE, is portable. In most systems it is possible to implement
>COMPILE, so it will generate code that is optimized to the same extent
>as code that is generated by the normal compilation process. **However,
>in some implementations there are two different "tokens" corresponding
>to a particular definition name: the normal "execution token" that is
>used while interpreting or with EXECUTE, and another "compilation
>token" that is used while compiling.**
>***It is not always possible to obtain the compilation token from the
>execution token. *** In these implementations, COMPILE, might not
>generate code that is as efficient as normally compiled code.
>
>So, the standard enshrines the concepts of interpretation and
>compilation semantics, but doesn't seem to give the programmer the
>tools to differentiate between the two behaviours.
Do you want to define non-default compilation semantics (as is
happening with S" and TO, but which has nothing to do with COMPILE, in
correct systems)?
Or do you want to optimize the default compilation semantics of words
like, say 2DUP; this can be implemented through the mechanism used for
defining compilation semantics, as described above (with special care
needed for [COMPILE]), but it's better to implement it as intelligent
COMPILE, (and then the issue described above does not happen), e.g.,
with SET-COMPILER in VFX.
>The crux of my argument is that everything should evolve around the
>XT, and the XT should be singular. Additional words could be
>standardised to provide access to the other behaviours; these words
>may produce a different XT. With this mechanism in place, tick still
>works like it always did. Tick does not need to nanny the programmer.
>
>' if >interp ( -- ixt ) \ produce interpretation semantics of if
>' if >comp ( -- cxt ) \ produce compilation semantics of if
Not that far from
: '' ( "name" -- nt ) parse-name find-name ;
'' if name>interpret ( xt0 )
'' if name>compile ( xt1 xt2 )
>Of course, in order to explicitly obtain the interpretation and runtime
>semantics of a word it must also be possible to set them. Stephen's
>SET-COMP is a step in the right direction in this regard.
VFX does not contain a word SET-COMP. The word SET-COMPILER changes
what COMPILE, does (and if used correctly, it does not changed how
COMPILE, behaves user-visibly, but only produces more efficient code),
not interpretation semantics. Concerning run-time semantics, that's
something that is typically referred to from compilation semantics,
and what it does is determined by writing compilation semantics
appropriately. E.g., in Gforth 0.7.0 the following is the compilation
semantics of .":
:noname [char] " parse postpone sLiteral postpone type ;
The run-time semantics is to push the string descriptor on the stack
and the to TYPE.
>I think this this the crux of the problem: The standard enshrines the
>concept of interpretation and compilation sematics/behaviours, but
>there's no way to set them.
Gforth has had INTERPRET/COMPILE: for 19 years. I have not used it
much, and I don't know about anybody using it much. I think we are
better off with just normal and immediate words.
>We need to be able to do something like:
>
>: (if) ... ... compilation semantics of if ... ...;
>: (if-i) ERROR-CODE THROW ( no interpretation semantics) ;
>: my-if state @ if (if) else (if-i) then ;
>' (if) ' if set-comp \ set compilation mode xt for set-comp and >comp
>' (if-i) ' if set-int \ set interpretation mode xt for set-int and >int
You could do that with INTERPRET/COMPILE: as follows:
' (if-i) ' (if) interpret/compile: if
but it's simpler to just write
: if (if) ; immediate compile-only
Concerning MY-IF, not sure what that monstrosity is there for.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-19 12:55 +0000 |
| Message-ID | <2015Jun19.145515@mips.complang.tuwien.ac.at> |
| In reply to | #39819 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>If you take out all ambiguities what does remain? How much of it? I said there are TOO MANY ambiguities.
If you want fewer ambiguous conditions, a way to get there is to make
proposals for removing them. But if practice is diverging in an area,
it will be a lot of work to convince implementors and programmers to
abandon their current practice.
>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.
It's also about what the results of FIND and ' are.
>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!
This is a case where the common (universal?) practice is to keep
control-flow items on the data stack. What is not common practice is
how big the control-flow items are, so there is little benefit to be
gained by portable programs from knowing that the control-flow items
are on the data stack. I guess that's why the option of a
separate control-flow stack was introduced in Forth-94.
In any case, if you think that the standard should be changed to
guarantee a separate control-flow stack to programs, you could make an
RfD. But my experience tells me that you can expect quite a bit of
resistance from system implementors.
>I would want it said clearly in the next standard (that tick find etc to return
>an xt)
"An xt". Sure, one can produce "an xt". That does not make any
program more portable than it is now, however. Now if you want to
make it tighter by specifying more closely what the xt should do when
EXECUTEd or COMPILE,d, this is an area that has been discussed a lot
over the years. There are various conflicting requirements around,
and conflicting opinions about the right solution. Good luck in
getting a consensus for your favourite solution.
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-18 10:00 -0700 |
| Message-ID | <5a2e18bb-d439-41b9-b545-6c103bbeeda4@googlegroups.com> |
| In reply to | #39818 |
On Thursday, June 18, 2015 at 1:27:21 AM UTC-7, Alex McDonald wrote: > on 18/06/2015 08:15:47, Mark Wills wrote: > > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: > >> And now it's easy to hide behind "ambiguous conditions" and claim that your > >> system is standard. > > > > Exactly. You could take (say) three Forth systems, all of which could > > exhibit different behaviour under certain conditions, and yet all of > > them would be "standard". So, your program *may* work as intended, or > > it *may* not. Given that the purpose of the standard is to promote > > portability, it's not a very good state of affairs, especially after > > some 30 odd years. > > This doesn't make sense. Either a system conforms to the standard or it > doesn't. The guarantee that a standard makes is that if you write > conforming programs, then they will work. It also says that if you write > for the ambiguities it might not work. So, you're saying that the use of tick or FIND is an example of: "if you write for the ambiguities it might not work." Any Forth programmer who dares to use tick or FIND is a trouble-maker who is using an esoteric ambiguous aspect of the language --- such trouble-makers deserve to have their programs fail to compile (gForth), fail at run-time (VFX), or work on one version of a compiler but fail on the next version of the same compiler --- in fact, such trouble-makers deserve to be water-boarded by the CIA until they confess to being terrorists and provide the names and addresses of other Forth programmers who are also so audacious as to use tick or FIND to obtain the xt of words like IF and semicolon. > 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. Nobody actually "does standards for a living" --- this is no more believable than Elizabeth Rather saying that she works for the NASA, or Juergen Pintaske taking credit for the Philae mission. Also, a programming language standard should require specific effects for all inputs to every function. If it doesn't, then sooner or later somebody will write a program that gives an input to a function and will be mighty upset when he is told that this is an "ambiguous condition" and hence any result is legal. Also, there are a small and finite number of words in the dictionary, and all of them have xt values --- it is straight-forward for tick and FIND to return a valid xt for all of them, but a compiler has to be sabotaged (special-case code needs to be written) for tick and/or FIND to fail on some words and work on other words. > If there's one > 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. A good standard should standardize behavior, but should not standardize implementation. Every standard system should behave the same, although they may be implemented differently internally. Similarly, all cars behave the same (there may be differences such as how much acceleration they have, but the fundamental behavior is the same) --- they may be implemented differently though (for example: have a piston-engine or a rotary-engine under the hood). Unfortunately, an ANS-Forth compiler that uses the data-stack as the control-flow stack will behave differently from an ANS-Forth compiler that makes the control-flow stack distinct from the data-stack --- portable programs have to assume the worst-case scenario (that the stacks are the same) --- anybody who assumes the best-case scenario (that they stacks are distinct) must, as Elizabeth Rather infamously said: "just declare a dependency and forge ahead!" > 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. ANS-Forth got pretty much everything wrong --- this is what happens when you put a salesperson rather than a programmer in charge of standardization. Also, making tick and FIND work properly doesn't require "major re-engineering work" --- my disambiguifiers do the job.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-18 20:56 +0100 |
| Message-ID | <mlv7na$a9a$1@dont-email.me> |
| In reply to | #39831 |
on 18/06/2015 18:00:51, wrote: > On Thursday, June 18, 2015 at 1:27:21 AM UTC-7, Alex McDonald wrote: >> on 18/06/2015 08:15:47, Mark Wills wrote: >> > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: >> >> And now it's easy to hide behind "ambiguous conditions" and claim that > your >> >> system is standard. >> > >> > Exactly. You could take (say) three Forth systems, all of which could >> > exhibit different behaviour under certain conditions, and yet all of >> > them would be "standard". So, your program *may* work as intended, or >> > it *may* not. Given that the purpose of the standard is to promote >> > portability, it's not a very good state of affairs, especially after >> > some 30 odd years. >> >> This doesn't make sense. Either a system conforms to the standard or it >> doesn't. The guarantee that a standard makes is that if you write >> conforming programs, then they will work. It also says that if you write >> for the ambiguities it might not work. > > So, you're saying that the use of tick or FIND is an example of: "if > you wr ite for the ambiguities it might not work." Any Forth > programmer who dares to use tick or FIND is a trouble-maker who is > using an esoteric ambiguous a spect of the language --- such > trouble-makers deserve to have their program s fail to compile > (gForth), fail at run-time (VFX), or work on one version of a compiler > but fail on the next version of the same compiler --- in fact , such > trouble-makers deserve to be water-boarded by the CIA until they con > fess to being terrorists and provide the names and addresses of other > Forth programmers who are also so audacious as to use tick or FIND to > obtain the xt of words like IF and semicolon. The standard is quite clear. What you would do with the tick of, say, IF, is beyond me. It has no interpretation semantics. Go waterboard yourself if you must. > >> 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. > > Nobody actually "does standards for a living" --- this is no more > believabl e than Elizabeth Rather saying that she works for the NASA, > or Juergen Pint aske taking credit for the Philae mission. DMTF OSDDC (multiple standards), IETF NFS (standard, see various RFCs), SNIA ESF (educational, vice chair) SNIA CDMI (ISO standard, see http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf) SNIA CSI (educational, I'm the chair) SNIA Europe (educational, board member), OASIS CAMP (technical, see acknowledgment http://docs.oasis-open.org/camp/camp-spec/v1.1/cs01/camp-spec-v1.1- cs01.html#_Toc403920806) and TOSCA (technical, although I'm not as actve in CAMP and TOSCA as I was). I'm active in promoting OpenStack as a "de facto" standard; I was in Vancouver last month for the OpenStack Summit. I chair the SNIA Cloud Storage Initiative (CSI), where we have just introduced a conformance test program for CDMI. Next week I'm hosting the CDMI technical work group in Edinburgh; we're doing what we call a plugfest where we test for conformance against the CDMI standard. http://cloudplugfest.us4.list-manage.com/subscribe?u=3c5c8a161730d95b6194ae841&id=c9dc03fdec I do standards for a living. You? > > Also, a programming language standard should require specific effects > for a ll inputs to every function. If it doesn't, then sooner or later > somebody w ill write a program that gives an input to a function and > will be mighty up set when he is told that this is an "ambiguous > condition" and hence any res ult is legal. That's because no-one can anticipate every case. > > Also, there are a small and finite number of words in the dictionary, > and a ll of them have xt values --- it is straight-forward for tick > and FIND to r eturn a valid xt for all of them, but a compiler has to > be sabotaged (speci al-case code needs to be written) for tick and/or > FIND to fail on some word s and work on other words. Pass. I don't know, and I suspect you're guessing too. > >> If there's one >> 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. > > A good standard should standardize behavior, but should not > standardize imp lementation. Every standard system should behave the > same, although they ma y be implemented differently internally. > Similarly, all cars behave the sam e (there may be differences such as > how much acceleration they have, but th e fundamental behavior is the > same) --- they may be implemented differently though (for example: > have a piston-engine or a rotary-engine under the hoo d). > > Unfortunately, an ANS-Forth compiler that uses the data-stack as the > contro l-flow stack will behave differently from an ANS-Forth compiler > that makes the control-flow stack distinct from the data-stack --- > portable programs h ave to assume the worst-case scenario (that the > stacks are the same) --- an ybody who assumes the best-case scenario > (that they stacks are distinct) mu st, as Elizabeth Rather infamously > said: "just declare a dependency and for ge ahead!" Precisely. You cannot fill up your electric car with fuel suitable for an internal combustion engine. > >> 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. > > ANS-Forth got pretty much everything wrong --- this is what happens > when yo u put a salesperson rather than a programmer in charge of > standardization. You'd have a taxi driver do it instead? > > Also, making tick and FIND work properly doesn't require "major > re-engineer ing work" --- my disambiguifiers do the job. > Then why are you complaining? (As an aside, I can't get them to work on my system.)
[toc] | [prev] | [next] | [standalone]
| From | Hannu Vuolasaho <vuokkosetae@gmail.com> |
|---|---|
| Date | 2015-06-19 03:13 +0300 |
| Message-ID | <mlvmpe$2js$1@dont-email.me> |
| In reply to | #39836 |
On 18.06.2015 22:56, Alex McDonald wrote: > on 18/06/2015 18:00:51, wrote: >> On Thursday, June 18, 2015 at 1:27:21 AM UTC-7, Alex McDonald wrote: >>> on 18/06/2015 08:15:47, Mark Wills wrote: >>>> On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: >>>>> And now it's easy to hide behind "ambiguous conditions" and claim that >> your >>>>> system is standard. > > DMTF OSDDC (multiple standards), IETF NFS (standard, see various RFCs), > SNIA ESF (educational, vice chair) SNIA CDMI (ISO standard, see > http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf) SNIA CSI > (educational, I'm the chair) SNIA Europe (educational, board member), > OASIS CAMP (technical, see acknowledgment > http://docs.oasis-open.org/camp/camp-spec/v1.1/cs01/camp-spec-v1.1- > cs01.html#_Toc403920806) and TOSCA (technical, although I'm not as actve > in CAMP and TOSCA as I was). I'm active in promoting OpenStack as a "de > facto" standard; I was in Vancouver last month for the OpenStack Summit. > I chair the SNIA Cloud Storage Initiative (CSI), where we have just > introduced a conformance test program for CDMI. Next week I'm hosting the > CDMI technical work group in Edinburgh; we're doing what we call a > plugfest where we test for conformance against the CDMI standard. > http://cloudplugfest.us4.list-manage.com/subscribe?u=3c5c8a161730d95b6194ae841&id=c9dc03fdec > > I do standards for a living. You? > For one thing to say about different forth implementations, I believe most of them document where they are non-conforming and how they differ. As you have quite long list of standards, can you give your opinion how those standards are conformed by implementers and how they document when they differ? I think forth has quite good standard discipline. Best regards, Hannu Vuolasaho
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-19 08:37 +0100 |
| Message-ID | <mm0gor$2s9$1@dont-email.me> |
| In reply to | #39847 |
on 19/06/2015 01:13:35, Hannu Vuolasaho wrote: > On 18.06.2015 22:56, Alex McDonald wrote: >> on 18/06/2015 18:00:51, wrote: >>> On Thursday, June 18, 2015 at 1:27:21 AM UTC-7, Alex McDonald wrote: >>>> on 18/06/2015 08:15:47, Mark Wills wrote: >>>>> On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: >>>>>> And now it's easy to hide behind "ambiguous conditions" and claim that >>> your >>>>>> system is standard. > >> >> DMTF OSDDC (multiple standards), IETF NFS (standard, see various RFCs), >> SNIA ESF (educational, vice chair) SNIA CDMI (ISO standard, see >> http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf) SNIA CSI >> (educational, I'm the chair) SNIA Europe (educational, board member), >> OASIS CAMP (technical, see acknowledgment >> http://docs.oasis-open.org/camp/camp-spec/v1.1/cs01/camp-spec-v1.1- >> cs01.html#_Toc403920806) and TOSCA (technical, although I'm not as actve >> in CAMP and TOSCA as I was). I'm active in promoting OpenStack as a "de >> facto" standard; I was in Vancouver last month for the OpenStack Summit. >> I chair the SNIA Cloud Storage Initiative (CSI), where we have just >> introduced a conformance test program for CDMI. Next week I'm hosting the >> CDMI technical work group in Edinburgh; we're doing what we call a >> plugfest where we test for conformance against the CDMI standard. >> http://cloudplugfest.us4.list-manage.com/subscribe?u=3c5c8a161730d95b6194ae841&id=c9dc03fdec >> >> I do standards for a living. You? >> > > For one thing to say about different forth implementations, I believe > most of them document where they are non-conforming and how they > differ. > > As you have quite long list of standards, can you give your opinion > how those standards are conformed by implementers and how they > document when they differ? For NFS, the conformation is very high indeed. The specification (especially for NFSv4 which exceeeds 600 pages) requires very high quality engineering, since the NFS clients and NFS servers are rarely if ever written by the same vendor. Interoperability is the whole reason for this standard, although there are a number of optional features in NFSv4.x, all of which have fallback options should the client request something the server doesn't support. The IETF NFS process only formalizes running code; no-one proposes thoeretical standards here. The philosophy is "running code and rough consensus". CDMI is newer, and there are fewer clients and servers. The intention is to provide a superset of Amazon's S3 and OpenStack Swift. We're in early days, but already have a number of errata where we simply got it wrong because of corner cases. This standard is a little unusual in that it proposes standardising experimental features that have few implementations; but that's because we can forsee commercial use cases where even a problematic standard will have applicability. These standard extensions will be fixed as we gain experience. > > I think forth has quite good standard discipline. > > Best regards, > Hannu Vuolasaho >
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-06-18 16:33 -0400 |
| Subject | WAS: bug in VFX... IS: More rants from Rantman of Rantland |
| Message-ID | <mlv9ta$hqm$1@dont-email.me> |
| In reply to | #39831 |
On 6/18/2015 1:00 PM, hughaguilar96@gmail.com wrote: <a bunch of ranting stuff, hard to read and not worth the effort> "It is better to light a single candle than to curse the darkness." -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-06-19 05:19 -0400 |
| Subject | Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland |
| Message-ID | <op.x0gz55hayfako5@localhost> |
| In reply to | #39841 |
On Thu, 18 Jun 2015 16:33:58 -0400, rickman <gnuarm@gmail.com> wrote: > On 6/18/2015 1:00 PM, hughaguilar96@gmail.com wrote: > <a bunch of ranting stuff, hard to read and not worth the effort> TL;DR will suffice. > "It is better to light a single candle than to curse the darkness." > Is it? ... I have question the logic of that. If you know you're surrounded by a pack of extremely hungry wolves, do you really want to see what's coming next? Rod Pemberton -- It's time to put an end to gun violence! Use a hammer ...
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-06-19 13:38 +0100 |
| Subject | Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland |
| Message-ID | <mm12e0$uab$1@dont-email.me> |
| In reply to | #39841 |
On 18/06/2015 21:33, rickman wrote: > On 6/18/2015 1:00 PM, hughaguilar96@gmail.com wrote: > > <a bunch of ranting stuff, hard to read and not worth the effort> > > "It is better to light a single candle than to curse the darkness." > Not if you've got a gas leak -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-06-19 12:29 -0400 |
| Subject | Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland |
| Message-ID | <mm1fv9$kmq$1@dont-email.me> |
| In reply to | #39866 |
On 6/19/2015 8:38 AM, Gerry Jackson wrote: > On 18/06/2015 21:33, rickman wrote: >> On 6/18/2015 1:00 PM, hughaguilar96@gmail.com wrote: >> >> <a bunch of ranting stuff, hard to read and not worth the effort> >> >> "It is better to light a single candle than to curse the darkness." >> > > Not if you've got a gas leak I think that even without the candle i can see why Forth has remained where it is over the last decade or two. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-06-19 17:53 -0400 |
| Subject | Re: WAS: bug in VFX... IS: More rants from Rantman of Rantland |
| Message-ID | <op.x0hy39cyyfako5@localhost> |
| In reply to | #39875 |
On Fri, 19 Jun 2015 12:29:42 -0400, rickman <gnuarm@gmail.com> wrote: > On 6/19/2015 8:38 AM, Gerry Jackson wrote: >> On 18/06/2015 21:33, rickman wrote: >>> On 6/18/2015 1:00 PM, hughaguilar96@gmail.com wrote: >>> <a bunch of ranting stuff, hard to read and not worth the effort> >>> >>> "It is better to light a single candle than to curse the darkness." >>> >> >> Not if you've got a gas leak > > I think that even without the candle i can see why Forth has > remained where it is over the last decade or two. Everybody is beautiful in the dark. Only some people look good in the light. Do you really want to see all the rest? Rod Pemberton -- It's time to put an end to gun violence! Use a hammer ...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-19 12:07 +0000 |
| Message-ID | <2015Jun19.140757@mips.complang.tuwien.ac.at> |
| In reply to | #39814 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> The ANS-Forth document (4.1.2.) "Ambiguous Conditions" lists the following as an ambiguous condition: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."
>>
>I consider this a mistake. What's ambiguous in obtaining an xt? FIND, tick and co.
>should deliver an xt if the word is findable, simple as that.
>Oh, if the word doesn't have interpretation semantics (there may be "compile-only" words - ok)
>then the word itself may abort.
Let's take an example:
defer endif immediate
' then is endif
: foo if endif ;
In Gforth 0.7.0 this produces:
...
' then is endif
:2: Cannot tick compile-only word (try COMP' ... DROP)
' >>>then<<< is endif
In vfxlin 4.71 this produces:
...
: foo if endif ;
Err# -14 ERR: Attempt to interpret a compile only definition.
-> : foo if endif ;
Somehow I think that Gforth's error message is more helpful
(unfortunately, it is not as helpful in the current development
version), and that it is also more helpful to report the error right
away rather than much later, potentially in a different context, which
may be (as in this case) confusing.
>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".
Yes, when there is no common practice, but instead diverging practice,
things are not standardized; either outright (by not including the
divergent area in the standard), or by having the part where we have
common practice standardized, and by stating explicitly, that the
divergent part is an ambiguous condition (or by explicitly specifying
the options, as is done for / MOD /MOD).
- 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-19 12:55 +0000 |
| Message-ID | <55840e9b.78522916@news.eternal-september.org> |
| In reply to | #39867 |
On Fri, 19 Jun 2015 12:07:57 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Let's take an example: > >defer endif immediate >' then is endif >: foo if endif ; > >In Gforth 0.7.0 this produces: > >... >' then is endif >:2: Cannot tick compile-only word (try COMP' ... DROP) >' >>>then<<< is endif > >In vfxlin 4.71 this produces: > >... >: foo if endif ; >Err# -14 ERR: Attempt to interpret a compile only definition. > -> : foo if endif ; The time frame of the error message is a consequence of what xts are assumed to be there for. If you assume that an xt can only be EXECUTEd or COMPILE,d then your attitude has a point. I take the original ANS perspective that the xt is a token for access to the details of a word, including all those things beyond just execution and compilation. The second point of view (mine) requires these services (even if not standardised) for words such as IF and THEN. Hence, with my point of view, all words have xts and the all the xt-consuming tools work. I think that my view is more Forth-ish, even if the ANS and Forth-2012 standards permit your view. Your view leads to horrors such as name tokens and burial of tools. If every word is tickable, Forth is simpler, both conceptually and in terms of implementation. 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-20 15:36 +0000 |
| Subject | The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) |
| Message-ID | <2015Jun20.173600@mips.complang.tuwien.ac.at> |
| In reply to | #39868 |
stephen@mpeforth.com (Stephen Pelc) writes:
>The time frame of the error message is a consequence of what xts are
>assumed to be there for. If you assume that an xt can only be
>EXECUTEd or COMPILE,d then your attitude has a point. I take the
>original ANS perspective that the xt is a token for access to
>the details of a word, including all those things beyond just
>execution and compilation.
There is no such perspective in ANS Forth. The only thing you can do
with an xt in ANS Forth (apart from the things that you can do with
every cell) is to EXECUTE it, to COMPILE, it, and, for CREATEd words,
to >BODY it. In ANS Forth you cannot get the immediate flag from the
xt, you cannot get the name from the xt, you cannot print the name
from the xt, you cannot get the compilation semantics of the word, if
the xt represents the interpretation semantics, you cannot get the
interpretation semantics if the word represents the compilation
semantics, you cannot extract what kind of word it is, not even if
>BODY is applicable or not, nor anything else except the three things
stated above.
Oh, and concerning your belief that everything should be doable from
an xt with one word, ANS Forth did not take that perspective either:
It gives us the (in your eyes) evil navigation word >BODY, instead of
>BODY@ >BODY! >BODY-2@ >BODY-2! >BODY-F@ >BODY-F! and
>BODY-FIELD-@ etc. (with the field passed as xt or offset).
Actually, for >BODY, the alternative that is more in line with your
"no navigation words" view would be to implement the xt as body
address, so >BODY becomes unnecessary. (Why does VFX not do it that
way?) But one cannot do that for all fields, and if you tried, it
would result in combo-words like the ones above, and you have already
demonstrated that by proposing the words
interp-execute
comp-execute
interp-compile,
comp-compile,
instead of the factored variants
name>interp execute
name>comp execute
name>interp compile,
name>comp swap postpone literal compile,
>I think that my view is more Forth-ish, even if the ANS and Forth-2012
>standards permit your view. Your view leads to horrors such as
>name tokens and burial of tools.
Name tokens are not a horror, and no tool is buried. OTOH, I find a
system that reports an error where it happens easier to use. The
system even gives a nice error message that tells the user what he may
have wanted to achieve (if ticking IF was not an oversight). In
contrast, in your system the user gets an unhelpful and misleading
error message, possibly far from the place where the error happened.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <boo@fasdfrewar.cdm> |
|---|---|
| Date | 2015-06-20 14:01 -0400 |
| Subject | Re: The meaning of xt in Forth-94 (was: bug in VFX --- IF does't work) |
| Message-ID | <op.x0jiz1mtyfako5@localhost> |
| In reply to | #39889 |
On Sat, 20 Jun 2015 11:36:00 -0400, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > stephen@mpeforth.com (Stephen Pelc) writes: >> The time frame of the error message is a consequence of what xts are >> assumed to be there for. If you assume that an xt can only be >> EXECUTEd or COMPILE,d then your attitude has a point. I take the >> original ANS perspective that the xt is a token for access to >> the details of a word, including all those things beyond just >> execution and compilation. > > There is no such perspective in ANS Forth. The only thing you can do > with an xt in ANS Forth (apart from the things that you can do with > every cell) is to EXECUTE it, to COMPILE, it, and, for CREATEd words, > to >BODY it. In ANS Forth you cannot get the immediate flag from the > xt, you cannot get the name from the xt, you cannot print the name > from the xt, you cannot get the compilation semantics of the word, if > the xt represents the interpretation semantics, you cannot get the > interpretation semantics if the word represents the compilation > semantics, you cannot extract what kind of word it is, not even if > >BODY is applicable or not, nor anything else except the three things > stated above. You used "cannot" a lot here to Stephen. Do you actually mean "cannot"? I.e., if someone attempts to implement Forth with a threaded interpreter as DTC or ITC, they *will* be able to get the name from the xt, get immediate flag, and perform other accesses to the word from the xt. Once before, I asked you if this meant that ANS Forth prohibited threaded implementations of Forth and you said that no it didn't. I.e., by "cannot" I would take that to mean I must code up something extra for a threaded code Forth to prohibit xts from being used for those ANS unlisted purposes. Rod Pemberton -- It's time to put an end to gun violence! Use a hammer ...
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-20 08:33 -1000 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <X76dnS3t0JaSLxjInZ2dnUU7-YOdnZ2d@supernews.com> |
| In reply to | #39896 |
On 6/20/15 8:01 AM, Rod Pemberton wrote: > On Sat, 20 Jun 2015 11:36:00 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> stephen@mpeforth.com (Stephen Pelc) writes: > >>> The time frame of the error message is a consequence of what xts are >>> assumed to be there for. If you assume that an xt can only be >>> EXECUTEd or COMPILE,d then your attitude has a point. I take the >>> original ANS perspective that the xt is a token for access to >>> the details of a word, including all those things beyond just >>> execution and compilation. >> >> There is no such perspective in ANS Forth. The only thing you can do >> with an xt in ANS Forth (apart from the things that you can do with >> every cell) is to EXECUTE it, to COMPILE, it, and, for CREATEd words, >> to >BODY it. In ANS Forth you cannot get the immediate flag from the >> xt, you cannot get the name from the xt, you cannot print the name >> from the xt, you cannot get the compilation semantics of the word, if >> the xt represents the interpretation semantics, you cannot get the >> interpretation semantics if the word represents the compilation >> semantics, you cannot extract what kind of word it is, not even if >> >BODY is applicable or not, nor anything else except the three things >> stated above. > > You used "cannot" a lot here to Stephen. Do you actually mean "cannot"? > I.e., if someone attempts to implement Forth with a threaded interpreter > as DTC or ITC, they *will* be able to get the name from the xt, get > immediate flag, and perform other accesses to the word from the xt. Once > before, I asked you if this meant that ANS Forth prohibited threaded > implementations of Forth and you said that no it didn't. I.e., by > "cannot" I would take that to mean I must code up something extra for > a threaded code Forth to prohibit xts from being used for those ANS > unlisted purposes. "Can" and "cannot" in reference to ANS Forth should be taken to mean "guaranteed to be able to" do whatever. In other words, it is *permissable* for a system to provide you a way to get to a name from an xt, for example, but standard systems are not *required* to do that. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-20 21:18 -0700 |
| Subject | Re: The meaning of xt in Forth-94 |
| Message-ID | <b04b0f47-685b-4061-8422-91b75908aee9@googlegroups.com> |
| In reply to | #39900 |
On Saturday, June 20, 2015 at 11:33:51 AM UTC-7, Elizabeth D. Rather wrote: > On 6/20/15 8:01 AM, Rod Pemberton wrote: > > On Sat, 20 Jun 2015 11:36:00 -0400, Anton Ertl > > <anton@mips.complang.tuwien.ac.at> wrote: > >> stephen@mpeforth.com (Stephen Pelc) writes: > > > >>> The time frame of the error message is a consequence of what xts are > >>> assumed to be there for. If you assume that an xt can only be > >>> EXECUTEd or COMPILE,d then your attitude has a point. I take the > >>> original ANS perspective that the xt is a token for access to > >>> the details of a word, including all those things beyond just > >>> execution and compilation. > >> > >> There is no such perspective in ANS Forth. The only thing you can do > >> with an xt in ANS Forth (apart from the things that you can do with > >> every cell) is to EXECUTE it, to COMPILE, it, and, for CREATEd words, > >> to >BODY it. In ANS Forth you cannot get the immediate flag from the > >> xt, you cannot get the name from the xt, you cannot print the name > >> from the xt, you cannot get the compilation semantics of the word, if > >> the xt represents the interpretation semantics, you cannot get the > >> interpretation semantics if the word represents the compilation > >> semantics, you cannot extract what kind of word it is, not even if > >> >BODY is applicable or not, nor anything else except the three things > >> stated above. > > > > You used "cannot" a lot here to Stephen. Do you actually mean "cannot"? > > I.e., if someone attempts to implement Forth with a threaded interpreter > > as DTC or ITC, they *will* be able to get the name from the xt, get > > immediate flag, and perform other accesses to the word from the xt. Once > > before, I asked you if this meant that ANS Forth prohibited threaded > > implementations of Forth and you said that no it didn't. I.e., by > > "cannot" I would take that to mean I must code up something extra for > > a threaded code Forth to prohibit xts from being used for those ANS > > unlisted purposes. > > "Can" and "cannot" in reference to ANS Forth should be taken to mean > "guaranteed to be able to" do whatever. In other words, it is > *permissable* for a system to provide you a way to get to a name from an > xt, for example, but standard systems are not *required* to do that. What good does it do if something is "permissable" if it isn't "required"? Do you understand that the purpose of a language standard is to make programs portable? You have previously said, in regard to the control-stack being distinct from the data-stack: "just declare a dependency and forge ahead!" All of this ambiguity is why ANS-Forth failed!!! As I said before, the ANS-Forth proponents' motto should be: "With ANS-Forth, anything is possible!" Do you know what a double-entendre is? Do you need this explained to you also?
[toc] | [prev] | [next] | [standalone]
Page 8 of 26 — ← Prev page 1 … 6 7 [8] 9 10 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web