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 23 of 26 — ← Prev page 1 … 21 22 [23] 24 25 26 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-08 12:07 +0000 |
| Message-ID | <2015May8.140712@mips.complang.tuwien.ac.at> |
| In reply to | #38866 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> I find it considerably harder to explain how to use COMPILE, if it
>> performs the compilation semantics, as you propose, rather than
>> compiling the EXECUTE semantics represented by the xt. Instead of
>> saying:
>>
>> "Here we want to delay execution by one level, so we use COMPILE,"
>>
>> I would have to say:
>
>No, Anton, you don't. You just say that COMPILE, performs the compilation
>semantics.
But it doesn't, not even on VFX:
: foo ." foo" ; immediate ok
: bar [ ' foo compile, ] ; ok
: bar2 foo ; foo ok
In BAR2 you can see the compilation semantics of FOO at work, in BAR
you see something different: the execution semantics of FOO being
appended to the current definition. This code works in this way on
every standard system, including VFX, so no system behaves the way you
want to document.
>You don't have to explain that it is different in the text
>interpreter vs. the tokenized form
What is that about? "Tokenized form" does not occur in the standard
nor any teaching material I know about Forth. Why should one have to
explain that?
>you don't have to explain that FIND may
>return two different xts depending on STATE, etc.
If you don't want to explain that, get rid of non-default
non-immediate compilation semantics. Or get rid of FIND.
>All you have to do for that is to let lose of your beloved equivalence,
>which is something your students don't know without being taught.
Somehow a number of people, including you, learned, and, more
importantly, used that equivalence without me having to teach them.
This equivalence has worked and has been used since the good old days
of threaded code when we still used "," instead of COMPILE,.
>> And of course the programmer would then use COMPILE, and have to
>> document the restriction on the xts,
>
>This documentation is required, anyhow. We document special compilaton
>semantics for every standard word which has it, and so should the user.
I am not referring to documenting words with special compilation
semantics, but words that take an xt as parameter, e.g., DEFINES in
mini-oof. Despite mini-oof having much more documentation from you
than any other code I have ssen from you, you fail to mention any
restrictions on the xts that you pass to it.
>> and another user would still pass
>> a word for which he used SET-COMPILER to implement non-default
>> compilation semantics (rather than SET-COMPSEM, which does not exist
>> in your setup), and he would get surprising results.
>
>No, because he has been taught that COMPILE, executes the SET-COMPILER
>semantics, and if you don't have it, it's a known default.
How should that user know that the xt passed to DEFINER in mini-oof
may be passed to COMPILE,?
>It's only
>surprising if you have a different mental model, which you do, but it's not
>something people are born with, and as far as I've seen the level of
>understanding of this concept, I think very few people share your mental
>model.
Concerning the use of COMPILE, as delayed EXECUTE, I think that many
people share that, because it already worked that way on the classic
systems. Concerning non-default non-immediate compilation semantics,
admittedly many people (maybe the majority) probably still think in
terms of STATE-smart words rather than in the Forth-94 concepts, so if
you make this a popularity contest, maybe we should standardize
STATE-smartness and be done with it.
>> Of course he would have made a mistake, just like someone who programs
>> "undefined behaviour" in C makes a mistake, but IMO laying such traps
>> is not the sign of a well-designed system, especially if we know ways
>> to avoid them, as we do here.
>
>No, we even create more potential pitfalls by having two concepts which seem
>to be related, but have clearly different effects. This is dangerous.
>People don't get sublte differences. You explain people that for the text
>interpreter, you need SET-COMPSEM to define compilation actions. And for
>the xt, you need SET-COMPILER to define the special COMPILE, action, which
>is closely related, but somehow different.
No, my explanation is: For changing the compilation semantics (e.g.,
for S"), you need SET-COMPSEM. For optimizing code generation
(without changing the meaning, e.g., for +), you use SET-COMPILER.
I see the difference between changing the meaning of a word and not
changing it as a fundamental difference, not a subtle one.
>DOES> used to be the concept of Forth which most people trying to learn
>Forth failed to understand. Words like SET-COMPILER and SET-COMPSEM are in
>the same ballpark. It is already difficult to teach them one of this
>concept, left alone two slightly different ones.
If it is too dificult, teach them none. Stick with IMMEDIATE for
compilation semantics, and leave optimization to the compiler.
However, if you want to provide a way to change compilation semantics,
and also provide them a way to do optimization, as you do, then
teaching one word for each purpose is easier than teaching one word
for both purposes with a number of caveats because that one word does
not work for the other purpose in all cases. So you advocate leaving
the caveats away; that's certainly going to make teaching simpler,
it's just that the result will be more bugs.
>> And even if nobody ever falls into this trap (like nobody ever fell
>> into the STATE-smart trap),
>
>Apart from you, I don't know any other example.
https://www.complang.tuwien.ac.at/forth/dpans-html/queries/a0007.html
The involved persons here are Wonyong Koh and Jonah Thomas. And
STATE-smartness was an issue long before I took any part in
discussions. Why, do you think, do we have CHAR and [CHAR] in
Forth-94 rather than the Forth-83 uncontrolled reference word ASCII?
>> there are still the burdens of the
>> increased complexity of explaining how to use COMPILE, correctly, the
>> burden on the programmer to decide whether to go for generality or
>> performance (and if the latter, the burden to document the
>> restrictions), and the burden on the user of the word containing
>> COMPILE, to find out whether the xt he wants to pass actually
>> satisfies the documented restrictions.
>
>No, that's wrong. That's under *your* assumption what COMPILE, should do.
>It's not going to do that after the change. Therefore, you don't have to
>think about it that way.
You mean, just because I would no longer think about it that way, all
the use-2 uses of COMPILE, and the thoughts of their programmers would
go away?
And even if it did, what about the future? Will no programmer ever
think again that he could speed his program up by using COMPILE,
instead of POSTPONE LITERAL POSTPONE EXECUTE?
>> If you want it simple,
>> go for single-xt+immediate-flag (compile-only is already too complex,
>> as we worked out); I suggested that, you rejected it, because
>> programmers will work around it with inadequate means to get their
>> separate compilation semantics;
>
>Well, maybe you are right and I should go that way. After all, just like
>the complaint about SET-COMPILER, there's only one guy who complains about
>STATE-smart: you. Ignore that guy, everybody else is happy ;-).
>
>Actually, it's not exactly that way.
And it's also not exactly that I am the only one who uses COMPILE, for
delayed EXECUTEion. Even you have done that, several times.
>Jenny Brien mentioned that you can't get cmForth-like dual-xt Forths
>completely standardized, and *that* particular problem was the reason: They
>used dual-xt for optimization, actually, worse: They used dual-xt to
>actually compile the primitives.
The particular problem with cmForth that has been discussed in the
past is what happens if somebody redefines a word that's in the
compilation wordlist. It would land in the ordinary wordlist and, in
compile state, would fail to shadow the earlier system-supplied
definition. That problem has nothing to do with optimization. One
could fix that problem, but the resulting system would be just more
complex and have no benefits over other dual-xt approaches such as the
three approaches we have used in Gforth.
There is a potential problem with using SET-COMPSEM for optimization,
though: [COMPILE] does not know whether the new compilation action
implements the default compilation semantics or not. However, the
dual problem occurs if you use SET-COMPILER for changing compilation
semantics; IIRC this has been discussed a few months ago. So this
problem occurs whenever one uses either approach for both purposes.
>And at least for return-stack words, that
>optimization is crucial, if you don't optimize, they don't work. I.e. in
>cmForth, you can't do
>
>['] >r compile,
>
>and get the expected result.
True, COMPILE, did not exist in cmForth's time, but other than that, I
see no particular problem. E.g., here's how iForth-2.1 does it (and,
looking at the code for FOO, it does not optimize in COMPILE,):
FORTH> : compile, compile, ;
Redefining compile, ok
FORTH> : foo [ ' >r compile, ] r> ; ok
FORTH> : bar >r r> ; ok
FORTH> : flip execute r> ; ok
FORTH> 1 foo . 1 ok
FORTH> 1 bar . 1 ok
FORTH> 1 ' >r flip . 1 ok
FORTH> see foo
Flags: ANSI
$08166700 : foo 8BC083ED048F4500 .@.m..E.
$08166708 call >R ( $0809F64C ) offset NEAR
E83F8FF3FF h?.
$0816670D mov ebx, [ebp 0 +] dword 8B5D00 .].
$08166710 lea ebp, [ebp 4 +] dword 8D6D04 .m.
$08166713 push ebx 53 S
$08166714 ; 8B450083C504 .E..E. ok
FORTH> see >r
Flags: COMPILE-ONLY, ANSI
$0809F64C pop ebx 5B [
$0809F64D sub ebp, 4 b# 83ED04 .m.
$0809F650 pop [ebp 0 +] dword 8F4500 .E.
$0809F653 jmp ebx FFE3 c ok
>These problems are all holes of the needlessly complicated model of the
>current standard.
Which problems?
1) Incorrect shadowing is an implementation issue in dual-wordlist
systems and does not occur at all in other dual-xt systems.
2) [COMPILE] problems occur for both SET-COMPSEM and SET-COMPILER when
they are used for the wrong purpose. A solution for that problem
(and, in the case of SET-COMPILER, others) is to use SET-COMPSEM only
for changing compilation semantics and to use SET-COMPILER only for
optimization.
3) "' >R COMPILE," can be made to work without an optimizing COMPILE,,
as demonstrated by iForth-2.1.
>> if you are right about that, and (a
>> significant number) of progammers want separate compilation semantics,
>> then it's these programmers who want the complexity. And then we
>> should do it properly rather than an "out-of-the-box shortcut" that
>> results in holes and traps.
>
>Treating compilation in text interpreter mode differently from compilation
>of xts is *not* "doing it properly", and you ignore the holes and traps this
>creates. See above for an example.
Your ' >R example shows that you do not need an optimizing COMPILE,.
>> In that case, the better approach is to go with SET-COMPSEM only (or
>> make SET-COMPILER behave as SET-COMPSEM).
>>
>> Then COMPILE, will work correctly in all cases.
>
>Anton, not "correctly", but "your way".
Not just my way, but the way specified in Forth-94 and Forth-2012, and
the way used in an unknown number of programs, including programs
written by you.
>> The only disadvantage is that, in a system
>> like VFX, while "+" will be compiled efficently from the
>> text-interrpeter, compiling it with "['] + compile," will be less
>> efficient.
>
>And "['] >r compile," might not work at all.
Sure, one can botch the implementation, but one can also botch the
implementation when using SET-COMPILER. iForth-2.1 demonstrates that
one can also get it right without an optimizing COMPILE,.
>> Of course, nothing would prevent VFX from having
>> SET-COMPILER for internal code generator use in addition to the
>> SET-COMPSEM that users use for defining separate compilation
>> semantics.
>
>That doesn't work. The "don't bury your tools" philosophy means it is
>documented and people will be able to use it. You now have to educate
>people why not use SET-COMPILER, why use SET-COMPSEM instead, even though it
>has the disadvantage that it works only in the text interpreter, and not
>with COMPILE,.
If this is a VFX word and MPE documents it, then they will have to
teach them that, yes.
I see no particular problem teaching them that, though:
"If you want to change the behaviour in compilation (e.g., because you
want to parse at compile time), use SET-COMPSEM. If the word behaves
as it should when you compile it, but you want to make it more
efficient, use SET-COMPILER."
>It is much easier to tell people that ' FOO is just *the* token for FOO (not
>"a STATE-dependent token, lacking the information whether it's immediate"),
>and that you can achive the interpreter part by doing EXECUTE and the
>compiler part by doing COMPILE, on it.
Sure, and that explanation works fine for words with default
compilation semantics only. Already immediate words don't work
the way you explain it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-08 18:26 +0100 |
| Message-ID | <miirha$dgv$1@dont-email.me> |
| In reply to | #38898 |
on 08/05/2015 13:07:14, wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>> I find it considerably harder to explain how to use COMPILE, if it >>> performs the compilation semantics, as you propose, rather than >>> compiling the EXECUTE semantics represented by the xt. Instead of >>> saying: >>> >>> "Here we want to delay execution by one level, so we use COMPILE," >>> >>> I would have to say: >> >>No, Anton, you don't. You just say that COMPILE, performs the compilation >>semantics. > > But it doesn't, not even on VFX: > >: foo ." foo" ; immediate ok >: bar [ ' foo compile, ] ; ok >: bar2 foo ; foo ok > > In BAR2 you can see the compilation semantics of FOO at work, in BAR > you see something different: the execution semantics of FOO being > appended to the current definition. This code works in this way on > every standard system, including VFX, so no system behaves the way you > want to document. > Neither it should, since it is the function of POSTPONE to append the compilation semantics. (An aside; POSTPONE, is quite useful.) >>you don't have to explain that FIND may >>return two different xts depending on STATE, etc. > > If you don't want to explain that, get rid of non-default > non-immediate compilation semantics. Or get rid of FIND. The latter. It's broken, and immediacy as a concept is becoming hard to justify when what is meant is the same interpretation and compilation effects. > >>All you have to do for that is to let lose of your beloved equivalence, >>which is something your students don't know without being taught. > > Somehow a number of people, including you, learned, and, more > importantly, used that equivalence without me having to teach them. > This equivalence has worked and has been used since the good old days > of threaded code when we still used "," instead of COMPILE,. Which was my point to Stephen Pelc upthread. COMPILE, is just , for non-ITC Forths, not an optimisation opportunity. > >>It's only >>surprising if you have a different mental model, which you do, but it's not >>something people are born with, and as far as I've seen the level of >>understanding of this concept, I think very few people share your mental >>model. > > Concerning the use of COMPILE, as delayed EXECUTE, I think that many > people share that, because it already worked that way on the classic > systems. Yes, I'm one of them. > Concerning non-default non-immediate compilation semantics, > admittedly many people (maybe the majority) probably still think in > terms of STATE-smart words rather than in the Forth-94 concepts, so if > you make this a popularity contest, maybe we should standardize > STATE-smartness and be done with it. > No, I'm not one of them. > >>DOES> used to be the concept of Forth which most people trying to learn >>Forth failed to understand. Words like SET-COMPILER and SET-COMPSEM are in >>the same ballpark. It is already difficult to teach them one of this >>concept, left alone two slightly different ones. > > If it is too dificult, teach them none. Stick with IMMEDIATE for > compilation semantics, and leave optimization to the compiler. Or rename them and have the concept & not the mechanism in the name. SET-COMPSEM becomes DO-WHEN-COMPILING SET-COMPILER becomes FOR-OPTIMIZING Or somesuch. SET-COMPILER and SET-COMPSEM are too down in the weeds.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-09 01:10 +0200 |
| Message-ID | <mijfn6$tus$1@dont-email.me> |
| In reply to | #38898 |
Anton Ertl wrote: >>No, Anton, you don't. You just say that COMPILE, performs the compilation >>semantics. > > But it doesn't, not even on VFX: > > : foo ." foo" ; immediate ok > : bar [ ' foo compile, ] ; ok > : bar2 foo ; foo ok Straw man, that's using a legacy feature which is there because the standard says you must have it - this way. >>You don't have to explain that it is different in the text >>interpreter vs. the tokenized form > > What is that about? "Tokenized form" does not occur in the standard > nor any teaching material I know about Forth. Why should one have to > explain that? The "t" in xt stands for "token". >>you don't have to explain that FIND may >>return two different xts depending on STATE, etc. > > If you don't want to explain that, get rid of non-default > non-immediate compilation semantics. Or get rid of FIND. I like to get rid of a number of needlessly complex things. I'm happy with getting rid of FIND. Since people like you oppose to the state-full simple concept of STATE+IMMEDIATE (it's simple, but then compilation and interpretation are states, not semantics), I'd like to have a state-less system which has the same simplicity. That would be EXECUTE for interpretation semantics and COMPILE, for compilation semantics. No STATE, no IMMEDIATE (except for legacy, and legacy means that legacy code compiles fine, but new code and old code doesn't have the same properties, and mixing them can lead to surprises in both ways). > Somehow a number of people, including you, learned, and, more > importantly, used that equivalence without me having to teach them. No, Anton. I'm not using this equivalence for corner cases. I'm using it only for words with default compilation semantics. > This equivalence has worked and has been used since the good old days > of threaded code when we still used "," instead of COMPILE,. But back then, we had STATE-smart for all those words with non-default compilation semantics, or plain and simple immediate compile-only words, and if I do ' " >CFA , in fig-Forth, I will get a word which parses and compiles a counted string when executed. Compilation semantics - it's immediate and compile-only. Your equivalence holds only for those words with default compilation semantics. > I am not referring to documenting words with special compilation > semantics, but words that take an xt as parameter, e.g., DEFINES in > mini-oof. Despite mini-oof having much more documentation from you > than any other code I have ssen from you, you fail to mention any > restrictions on the xts that you pass to it. It's there by example: All xts passed to defines in mini-oof are :noname xts. > How should that user know that the xt passed to DEFINER in mini-oof > may be passed to COMPILE,? By reading the documentation. The full source of mini-oof is part of the documentation. "There are two ways to achieve this with this OOF: first, you could use named words, and second, you could look up the vtable of the parent object. : :: ( class "name" -- ) ' >body @ + @ compile, ;" When you choose option 1 (named words, no :: needed), you'll get into the troubles you describe with SET-COMPSEM, too. > Concerning the use of COMPILE, as delayed EXECUTE, I think that many > people share that, because it already worked that way on the classic > systems. Since xts don't carry the immediacy flag with them, that model is too simplistic. As you notice, many people still think STATE-smart, and there, EXECUTE can be both interpretation and compilation semantics, depending on STATE. > Concerning non-default non-immediate compilation semantics, > admittedly many people (maybe the majority) probably still think in > terms of STATE-smart words rather than in the Forth-94 concepts, so if > you make this a popularity contest, maybe we should standardize > STATE-smartness and be done with it. Should be a relatively straight-forward job. Your problem seems to be that you don't want popularity to count, but a standard is about common practise, and there, popularity indeed counts. > No, my explanation is: For changing the compilation semantics (e.g., > for S"), you need SET-COMPSEM. For optimizing code generation > (without changing the meaning, e.g., for +), you use SET-COMPILER. > > I see the difference between changing the meaning of a word and not > changing it as a fundamental difference, not a subtle one. People do not think that way. When they extend a word like S" to work in interpretation, too, their mental model is that S" now does *the same thing* in interpretation mode and in compilation mode. So far, I've not seen a single case of these words where the need for that special compilation or interpretation semantics wasn't driven by the desire to make the word useful with identical syntax and effect both for interpretation and compilation. s" foo" is a string literal to foo is a value assignment object method is a method invocation This all regardless of compilation or interpretation. People who write such code *don't* want to change the meaning, rather the contrary: they want to preserve the meaning of these things. Since all these words are parsing words, they do indeed different things in compilation and interpretation. But that is an implementation detail. > If it is too dificult, teach them none. Stick with IMMEDIATE for > compilation semantics, and leave optimization to the compiler. Possible. The whole discussion was started by you, because you exposed problems understanding STATE+IMMEDIATE, and RFI 7 lists a number of real shortcomings. I suppose to take the examples of RFI 7 as test if the compiler technique is ok. Let's say, we want to count how many DUPs we compile in our source code: variable dup# :noname drop postpone dup 1 dup# +! ; : dup dup ; set-compiler It compiles correctly - tick it interprets correctly - tick what it compiles executes correctly - tick its tick compile and execute correctly, without or with little performance loss - tick [compile] works correctly - tick Anton's test: works on use 2 in OOP packages - tick Obviously it does work as Mitch Bradley expects it to work, and it even works as you expect it to work. Note that this dup here does not perform an optimization - it changes the compilation semantics of dup to *also* increment a counter at compile time. It's not a parsing word, though. Using state+immediate doesn't solve the problem. Using SET-COMPSEM results in a wrong number of counts with use 2 of that DUP, otherwise, it works fine, too. A more realistic example for this kind of stuff would be tracing changes to a variable. Let's define debug-variable: Variable debug! : debug-variable ( "name" -- ) variable [: debug! on variable, ;] set-compiler ; : ~var~ ( n addr -- ) dup body> >name .name ." from: " dup @ . ." to: " over . cr ; :noname drop debug! @ debug! off IF postpone ~var~ THEN postpone ! ; : ! ! ; set-compiler variable, is the default compiler for variables, i.e. >body postpone literal. So when I change a variable into a debug-variable, each time a store is performed afterwards, it will print a state change. debug-variable foo ok : test1 3 foo ! ; ok : test2 5 foo ! ; ok test1 foo from: 0 to: 3 ok test2 foo from: 3 to: 5 ok : test3 test1 test2 test1 ; ok test3 foo from: 5 to: 3 foo from: 3 to: 5 foo from: 5 to: 3 Doesn't work in interpretation state. Doesn't work with a late-bound ! as method. Doesn't work if there's some complicated pointer-juggling. A performance-penalty version could be made to work in more of those cases (depending how much performance you want to spend on that), so that stuff is an optimization over the naive version (where variable does that DEBUG! ON in a DOES> statement, and ! checks for that at run-time). > So you advocate leaving > the caveats away; that's certainly going to make teaching simpler, > it's just that the result will be more bugs. IMHO it's better to teach people about parsing words and recognizers, and why they should use recognizers instead of parsing words. > The involved persons here are Wonyong Koh and Jonah Thomas. And > STATE-smartness was an issue long before I took any part in > discussions. Why, do you think, do we have CHAR and [CHAR] in > Forth-94 rather than the Forth-83 uncontrolled reference word ASCII? Forth Inc. didn't have STATE at all, and they didn't like it. Probably for a reason. As explained above, STATE can do some things and can't do a lot of other things. And it's *not* just about optimization. And people don't want to change the semantics, it's just that parsing words need different implementations - it's not perceived as semantics change. > You mean, just because I would no longer think about it that way, all > the use-2 uses of COMPILE, and the thoughts of their programmers would > go away? Only the corner-case use-2 with special compilation semantics, compile-only words and such stuff is changing. You are inflating the problem. These cases already don't work as people might assume right now in a number of systems (and since assumtions may be different, with many people still thinking STATE-smart, it's not clear which system is the most unexpected one). > And even if it did, what about the future? Will no programmer ever > think again that he could speed his program up by using COMPILE, > instead of POSTPONE LITERAL POSTPONE EXECUTE? He usually can. It's a corner case where he can't. A corner case where it very likely won't work in many current Forth systems, either. We can continue as we do now, and say this sort of stuff is simply not supposed to work portably. Or we say it's supposed to work in the next standard, and we then have to chose how. STATE-smart, SET-COMPILER or dual- xt are already implemented, and the three behave different. > And it's also not exactly that I am the only one who uses COMPILE, for > delayed EXECUTEion. Even you have done that, several times. Sure. But not on your straw-man. >>These problems are all holes of the needlessly complicated model of the >>current standard. > > Which problems? The standard tries to wrap around two (Forth-94) or three (Forth-2012) different ways to implement things. That's always complicating things. > 1) Incorrect shadowing is an implementation issue in dual-wordlist > systems and does not occur at all in other dual-xt systems. That doesn't remove other dual-xt problems. > 2) [COMPILE] problems occur for both SET-COMPSEM and SET-COMPILER when > they are used for the wrong purpose. A solution for that problem > (and, in the case of SET-COMPILER, others) is to use SET-COMPSEM only > for changing compilation semantics and to use SET-COMPILER only for > optimization. [COMPILE] works only when you have a priori knowledge of what is immediate and what not. > 3) "' >R COMPILE," can be made to work without an optimizing COMPILE,, > as demonstrated by iForth-2.1. Hm, looks like iForth uses some sort of SET-COMPSEM to optimize? Is that the right approach? > Your ' >R example shows that you do not need an optimizing COMPILE,. Sure, nobody needs an optimizer. But you might want one. > Not just my way, but the way specified in Forth-94 and Forth-2012, and > the way used in an unknown number of programs, including programs > written by you. Straw man again: This use 2 works with words that have default compilation semantics, which are the non-critical words. Use 2 does exhibit considerable different behavior on the corner cases on current systems, all of them standard under Forth-2012. Some of them don't allow to tick the problematic words, others return STATE-smart xts, and so on. These use 2 as now are non-portable at least. If you want to keep all the non-portable code that exploits behavior on use 2 on different systems, we have to keep it as is: say that it is non-portable. Some people using use 2 with state-smart systems might want to keep the state-smartness, people using use 2 with dual-xt might want to preserve that semantics, and people using use 2 with SET-COMPILER systems might want to preserve their semantics. That is the real-world code. You are pretending that the real-world code out there is the code for dual-xt systems. As if there wasn't any SwiftForth (state-smart) or VFX (set-compiler). Your straw man is that COMPILE, would magically stop working on words with default compilation semantics. It doesn't! And the other straw man is that use 2 for non-default compilation semantics is somewhat crucial for you and everybody else. It can't be, because it doesn't work portable right now. It's not like the typical C standard lawyer who says we can break those programs, because they worked 20 years but the standard says it's UD. These programs are really non-portable right now across popular implementations. If we want to make the behavior of use 2 portable across popular implementations, two out of three have to give in. And it's real-world, not just like removing signed-magnitude and one's complement, which affects nobody. If we change to STATE+IMMEDIATE, SwiftForth users can keep their weird corner cases for use 2. If we change to dual-xt, Gforth users can keep their weird corner cases for use 2. And if we change to SET-COMPILER, VFX users can keep their weird corner cases for use 2. Since Gforth makes it the hardest to abuse use 2 (all compile-only words are non-tickable), it's probably the least impacted. >>It is much easier to tell people that ' FOO is just *the* token for FOO >>(not "a STATE-dependent token, lacking the information whether it's >>immediate"), and that you can achive the interpreter part by doing EXECUTE >>and the compiler part by doing COMPILE, on it. > > Sure, and that explanation works fine for words with default > compilation semantics only. If you change the concept, it works. > Already immediate words don't work the way you explain it. Immediate is a legacy concept, then marked as obsolescent. And I don't think you should explain two concepts for the same thing to newbies. I don't think you can have both and have a system that's easy to explain. That's the root of the problem now: We have a standard which tries to describe three different possible implementations with the same logical concept. That's not going to fly. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-12 16:13 +0000 |
| Message-ID | <2015May12.181357@mips.complang.tuwien.ac.at> |
| In reply to | #38901 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>>>No, Anton, you don't. You just say that COMPILE, performs the compilation
>>>semantics.
>>
>> But it doesn't, not even on VFX:
>>
>> : foo ." foo" ; immediate ok
>> : bar [ ' foo compile, ] ; ok
>> : bar2 foo ; foo ok
>
>Straw man, that's using a legacy feature which is there because the standard
>says you must have it - this way.
Are you sure you know what a straw man argument is?
Anyway, it's standard and every system implements it this way. So
it's not just common practice, but universal practice. You propose
changing that. You would need very good arguments for that, and you
failed to do that yet.
>>>You don't have to explain that it is different in the text
>>>interpreter vs. the tokenized form
>>
>> What is that about?
...
>The "t" in xt stands for "token".
No I don't have to explain that, I just explain that an execution
token stands for one semantics; EXECUTE executes it, and COMPILE,
appends it to the current definition. And I consider that simpler
than saying that an xt stands for a lot of different things, that
EXECUTE does one thing, and COMPILE, may do something completely
unrelated.
>I like to get rid of a number of needlessly complex things. I'm happy with
>getting rid of FIND. Since people like you oppose to the state-full simple
>concept of STATE+IMMEDIATE (it's simple, but then compilation and
>interpretation are states, not semantics), I'd like to have a state-less
>system which has the same simplicity.
What's wrong with
defer name>x \ not the Gforth word of the same name
: ] ['] name>compile is name>x ;
: [ [: name>interpret dup 0= -14 and throw ;] is name>x ;
\ and here the text interpreter:
parse-name find-name dup 0= -13 and throw name>x execute
>That would be EXECUTE for
>interpretation semantics and COMPILE, for compilation semantics. No STATE,
>no IMMEDIATE (except for legacy, and legacy means that legacy code compiles
>fine, but new code and old code doesn't have the same properties, and mixing
>them can lead to surprises in both ways).
IMMEDIATE fits nicely in the system above, and STATE could be
implemented to behave as it always has.
>> Somehow a number of people, including you, learned, and, more
>> importantly, used that equivalence without me having to teach them.
>
>No, Anton. I'm not using this equivalence for corner cases. I'm using it
>only for words with default compilation semantics.
That may be the case, but you have not documented that one must only
pass words with default compilation semantics to DEFINES in mini-oof.
>> This equivalence has worked and has been used since the good old days
>> of threaded code when we still used "," instead of COMPILE,.
>
>But back then, we had STATE-smart for all those words with non-default
>compilation semantics, or plain and simple immediate compile-only words, and
>if I do ' " >CFA , in fig-Forth, I will get a word which parses and compiles
>a counted string when executed. Compilation semantics - it's immediate and
>compile-only. Your equivalence holds only for those words with default
>compilation semantics.
No, it holds for all words in fig-Forth, including STATE-smart words.
STATE-smart words have other problems, but the equivalence between
EXECUTE and COMPILE, holds for them.
>> I am not referring to documenting words with special compilation
>> semantics, but words that take an xt as parameter, e.g., DEFINES in
>> mini-oof. Despite mini-oof having much more documentation from you
>> than any other code I have ssen from you, you fail to mention any
>> restrictions on the xts that you pass to it.
>
>It's there by example: All xts passed to defines in mini-oof are :noname
>xts.
That's not documentation. You pass only three xts to DEFINES, but I
don't think that you want users to think that they may pass only one
of these three xts.
>> How should that user know that the xt passed to DEFINER in mini-oof
>> may be passed to COMPILE,?
>
>By reading the documentation. The full source of mini-oof is part of the
>documentation.
>
>"There are two ways to achieve this with this OOF: first, you could use
>named words, and second, you could look up the vtable of the parent object.
>
>: :: ( class "name" -- ) ' >body @ + @ compile, ;"
So you expect that the user understands subtle implementation details
of mini-OOF in order to use it (such as the flow of the xt from
DEFINES to COMPILE,), but you don't tell that to the user.
>When you choose option 1 (named words, no :: needed), you'll get into the
>troubles you describe with SET-COMPSEM, too.
No, if the user writes a named word, there is no xt passed to the
COMPILE, in mini-oof. Sure, the user will get the compilation
semantics when he writes a named word in a definition, but that's very
familiar territory to users (they use the text interpreter a lot, much
more than ', EXECUTE, and COMPILE,).
>> Concerning the use of COMPILE, as delayed EXECUTE, I think that many
>> people share that, because it already worked that way on the classic
>> systems.
>
>Since xts don't carry the immediacy flag with them, that model is too
>simplistic.
Simple is not always better, but here it is. And anyway, it's common
practice.
>> Concerning non-default non-immediate compilation semantics,
>> admittedly many people (maybe the majority) probably still think in
>> terms of STATE-smart words rather than in the Forth-94 concepts, so if
>> you make this a popularity contest, maybe we should standardize
>> STATE-smartness and be done with it.
>
>Should be a relatively straight-forward job. Your problem seems to be that
>you don't want popularity to count, but a standard is about common practise,
>and there, popularity indeed counts.
I don't recommend STATE-smart words, but they are good-enough for the
few standard words with special compilation semantics, and I don't
recommend writing more words with special compilation semantics.
>> No, my explanation is: For changing the compilation semantics (e.g.,
>> for S"), you need SET-COMPSEM. For optimizing code generation
>> (without changing the meaning, e.g., for +), you use SET-COMPILER.
>>
>> I see the difference between changing the meaning of a word and not
>> changing it as a fundamental difference, not a subtle one.
>
>People do not think that way. When they extend a word like S" to work in
>interpretation, too, their mental model is that S" now does *the same thing*
>in interpretation mode and in compilation mode.
When they think so, they are thinking of the word plus the thing it
parses. Recognizers should replace that use.
Anyway, it should be clear to a programmer of a STATE-smart word that
it's not the same thing, because otherwise there would be no need for
STATE @ IF. I think they understand the difference, and when
appropriately documented, understand that they should use SET-COMPSEM
and not SET-COMPILER for such words.
>So far, I've not seen a single case of these words where the need for that
>special compilation or interpretation semantics wasn't driven by the desire
>to make the word useful with identical syntax and effect both for
>interpretation and compilation.
>
>s" foo" is a string literal
>to foo is a value assignment
>object method is a method invocation
>
>This all regardless of compilation or interpretation. People who write such
>code *don't* want to change the meaning, rather the contrary: they want to
>preserve the meaning of these things.
>
>Since all these words are parsing words, they do indeed different things in
>compilation and interpretation. But that is an implementation detail.
But it's obviously not an optimization. So use SET-COMPSEM, not
SET-COMPILER. Or better, define a recognizer.
>> If it is too dificult, teach them none. Stick with IMMEDIATE for
>> compilation semantics, and leave optimization to the compiler.
>
>Possible. The whole discussion was started by you, because you exposed
>problems understanding STATE+IMMEDIATE, and RFI 7 lists a number of real
>shortcomings. I suppose to take the examples of RFI 7 as test if the
>compiler technique is ok. Let's say, we want to count how many DUPs we
>compile in our source code:
>
>variable dup#
>:noname drop postpone dup 1 dup# +! ;
>: dup dup ; set-compiler
>
>It compiles correctly - tick
>it interprets correctly - tick
>what it compiles executes correctly - tick
>its tick compile and execute correctly, without or with little performance
>loss - tick
>[compile] works correctly - tick
>
>Anton's test: works on use 2 in OOP packages - tick
>
>Obviously it does work as Mitch Bradley expects it to work, and it even
>works as you expect it to work. Note that this dup here does not perform an
>optimization - it changes the compilation semantics of dup to *also*
>increment a counter at compile time.
No, it does not change the compilation semantics. It performs the
same compilation semantics, and adds instrumentation. And the
instrumentation you get with that is to count the number of times that
the xt of DUP is COMPILE,d.
>Using SET-COMPSEM results in a wrong number of counts with use 2 of that
>DUP, otherwise, it works fine, too.
It would count a different thing: How often the compilation semantics
of DUP is accessed. So it depends on what you want to access.
It would not work fine in all cases, however: [COMPILE] DUP would not
work properly, because SET-COMPSEM would make [COMPILE] think that DUP
has non-default compilation semantics, while it still has
(instrumented) default compilation semantics. If we wanted to be able
to instrument that, we would need a variant of SET-COMPSEM that marks
the word as still having default compilation semantics.
>> So you advocate leaving
>> the caveats away; that's certainly going to make teaching simpler,
>> it's just that the result will be more bugs.
>
>IMHO it's better to teach people about parsing words and recognizers, and
>why they should use recognizers instead of parsing words.
Yes.
>> You mean, just because I would no longer think about it that way, all
>> the use-2 uses of COMPILE, and the thoughts of their programmers would
>> go away?
>
>Only the corner-case use-2 with special compilation semantics, compile-only
>words and such stuff is changing. You are inflating the problem. These
>cases already don't work as people might assume right now in a number of
>systems
As long as we only have those few words, rarely a problem (and that
problem is covered in the standard by disallowing ticking these words).
But you suggest using SET-COMPILER instead of SET-COMPSEM not just for
these few words, but for defining words that might be used to define
many other words. I would not bet that nobody ever ticks the result
of such a defining word and never passes it to COMPILE,.
>> And even if it did, what about the future? Will no programmer ever
>> think again that he could speed his program up by using COMPILE,
>> instead of POSTPONE LITERAL POSTPONE EXECUTE?
>
>He usually can. It's a corner case where he can't. A corner case where it
>very likely won't work in many current Forth systems, either.
It certainly works for ordinary immediate words in all current Forth
systems.
>We can continue as we do now, and say this sort of stuff is simply not
>supposed to work portably. Or we say it's supposed to work in the next
>standard, and we then have to chose how. STATE-smart, SET-COMPILER or dual-
>xt are already implemented, and the three behave different.
I think the way to go for the standard is to leave them as-is and turn
them into legacy (and eventually obsolete) with recognizers. For a
system, the right thing to do is still deciding at parse/FIND time,
not later; the other solutions are good enough, though, as long as
their use is kept to a minimum.
>>>These problems are all holes of the needlessly complicated model of the
>>>current standard.
>>
>> Which problems?
>
>The standard tries to wrap around two (Forth-94) or three (Forth-2012)
>different ways to implement things. That's always complicating things.
>
>> 1) Incorrect shadowing is an implementation issue in dual-wordlist
>> systems and does not occur at all in other dual-xt systems.
>
>That doesn't remove other dual-xt problems.
What other problems?
>> 3) "' >R COMPILE," can be made to work without an optimizing COMPILE,,
>> as demonstrated by iForth-2.1.
>
>Hm, looks like iForth uses some sort of SET-COMPSEM to optimize? Is that
>the right approach?
I don't know what iForth actually uses. I would base optimization on
"COMPILE,", but basing it on compilation semantics is also possible
and does not lead to any problems except that you have to teach
[COMPILE] what is default compilation semantics and what is not; you
miss some (rare) optimization opportunities with that approach, however.
>> Your ' >R example shows that you do not need an optimizing COMPILE,.
>
>Sure, nobody needs an optimizer. But you might want one.
Sure, and hanging the optimizer on COMPILE, is fine; hanging special
compilation semantics on it is not.
>Your straw man is that COMPILE, would magically stop working on words with
>default compilation semantics.
No. My argument is that in the current standard the equivalence
between EXECUTE and COMPILE, holds for all xts you can get in a
standard program. If it doesn't, the system is non-standard. And it
does hold.
>If we want to make the behavior of use 2 portable across popular
>implementations, two out of three have to give in.
Nobody has to give in. It works already.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-13 00:11 +0200 |
| Message-ID | <mittol$47s$1@dont-email.me> |
| In reply to | #39036 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >> >>>>No, Anton, you don't. You just say that COMPILE, performs the >>>>compilation semantics. >>> >>> But it doesn't, not even on VFX: >>> >>> : foo ." foo" ; immediate ok >>> : bar [ ' foo compile, ] ; ok >>> : bar2 foo ; foo ok >> >>Straw man, that's using a legacy feature which is there because the >>standard says you must have it - this way. > > Are you sure you know what a straw man argument is? Sure. The german word is "Trugschluss". We have a legacy approach at compiler macros: that's IMMEDIATE, plus STATE for special compilation semantics. > Anyway, it's standard and every system implements it this way. So > it's not just common practice, but universal practice. You propose > changing that. You would need very good arguments for that, and you > failed to do that yet. Most of the problems with IMMEDIATE are already in RFI 7. That's not limited to STATE-smart words. > No I don't have to explain that, I just explain that an execution > token stands for one semantics; EXECUTE executes it, and COMPILE, > appends it to the current definition. And I consider that simpler > than saying that an xt stands for a lot of different things, that > EXECUTE does one thing, and COMPILE, may do something completely > unrelated. Anton, the simpler thing is that an xt is a number that represents a word. If you need three different tokens to represent a word (nt for the name, xt for execution and ct for compilation), you have a 1:3 relation. 3 is more than 1, having three different tokens, several converters back and forth is not simple. If you define a word that does two completely unrelated things depending on state, that's a bad idea. But if somebody does this bad thing, it's most consequential that it does this bad thing when encountered as name in the input stream as well as when encountered as xt. : weird ." foo" ; comp: drop ." bar" ; is a weird word, which prints "foo" in interpretation mode, and "bar" in compilation mode. It makes no sense to be that weird, but it is consistent behavior if ' weird execute prints that "foo" and ' weird compile, prints that "bar". COMPILE, does not something "completely unrelated", here it just compiles WEIRD. The only surprising element is the implementation of WEIRD, but it is consistent between textual representation and token representation. > What's wrong with > > defer name>x \ not the Gforth word of the same name > : ] ['] name>compile is name>x ; > : [ [: name>interpret dup 0= -14 and throw ;] is name>x ; > > \ and here the text interpreter: > parse-name find-name dup 0= -13 and throw name>x execute What's wrong with that? name>x has a variable stack effect. As long as you just EXECUTE that, it works fine. If you want to do something else (e.g. just resolve some names and let them be compiled or executed later), it's not going to work. Example for such tokenizing and later resolving: a dot parser for an OOP system that can parse something like "object.subobject.method". The proposed interpreter would look like this: defer do-xt ( xt -- ) : ] ['] compile, is do-xt ; : [ ['] execute is do-xt ; parse-name find-xt dup 0= -13 and throw do-xt do-xt has a simple, constant stack effect. There's only one kind of token, which can be used as universal token, not just as execution token (use xt>string instead of >name name>string to get at the name). Words wouldn't have flags anymore. For legacy code, you might have : immediate ['] execute set-compiler ; > IMMEDIATE fits nicely in the system above, and STATE could be > implemented to behave as it always has. You can always make tradeoffs between simplicity and compatibility. > That may be the case, but you have not documented that one must only > pass words with default compilation semantics to DEFINES in mini-oof. "By example" is good enough for the amount of documentation I made. > No, it holds for all words in fig-Forth, including STATE-smart words. > STATE-smart words have other problems, but the equivalence between > EXECUTE and COMPILE, holds for them. fig-Forth's " wasn't state-smart. It was compile-only. You got the compilation semantics if you did ' " >CFA ,. The "execution semantics" of " was to report an error, or silently just compile the string (IIRC, the latter). You keep on and on with ignoring that your equivalence doesn't work with compile-only immediate words. I don't know what to do. Once again: ' <compile-only+immediate> COMPILE, appends the compilation semantics, i.e. is equivalent to [COMPILE] and POSTPONE of that name. It's *not* equivalent to encountering that word in the text interpreter in interpretation state. I think your problem is that you stop half-way in the argument. The standard mandates: Equivalence 1: foo === ' foo execute \ in interpretation mode Equivalence 2: ' foo compile, === ' foo postpone literal postpone execute Equivalence 1 resulted in RFI 8, which says that ' is undefined if ' FOO EXECUTE doesn't equal to FOO (compile-only words). That means that equivalence 2 is meaningless for these cases, too, because ' FOO for a compile-only FOO is meaningless. We already agreed on that on EuroForth. And it's not just meaningless, it does not what people would expect it to do (in the current system). For a number of compile-only words, people can't know whether they are immediate or not (the standard doesn't tell). But here, if you want to do something like ' EXIT COMPILE,, it matters. In my proposed system, it doesn't matter. If EXIT is an alias to ;S, and has default compilation semantics, ['] EXIT COMPILE, will produce exactly the same effect as the Gforth EXIT, which cleans up the local stack, too. Gforth "avoids" this problem by not allowing to tick EXIT. I.e. you just can't do it. But it's pretty obvious what that ['] EXIT COMPILE, should do, and you can directly infer it from the standard. EXIT by specification has only execution semantics without interpretation semantics. >>It's there by example: All xts passed to defines in mini-oof are :noname >>xts. > > That's not documentation. You pass only three xts to DEFINES, but I > don't think that you want users to think that they may pass only one > of these three xts. Another straw man. Documentation by example means that you can savely follow the pattern laid out in the example. There are three :noname <some stuff> ; <class> defines <method> examples. People can and do recognize such patterns and are able to apply them. It's one of the things humans are pretty good at. >>: :: ( class "name" -- ) ' >body @ + @ compile, ;" > > So you expect that the user understands subtle implementation details > of mini-OOF in order to use it (such as the flow of the xt from > DEFINES to COMPILE,), but you don't tell that to the user. Yes, I do indeed assume that the target audience is capable of reading a few lines of Forth code. >>When you choose option 1 (named words, no :: needed), you'll get into the >>troubles you describe with SET-COMPSEM, too. > > No, if the user writes a named word, there is no xt passed to the > COMPILE, in mini-oof. If the user uses named words like this : base:method <some words> ; ' base:method base defines method and later : derived:method <some more words> base:method ; ' derived:method derived defines method base:method goes through the text interpreter, which COMPILE,s it. If there's a SET-COMPILER on base:method, this part will get executed. It's 100% the same situation. > Sure, the user will get the compilation > semantics when he writes a named word in a definition, but that's very > familiar territory to users (they use the text interpreter a lot, much > more than ', EXECUTE, and COMPILE,). The advantage of my approach is that there's a very straight-forward correspondence from the familiar territory to EXECUTE and COMPILE,. Much more straight-forward than the text interpreter is now. So when the people wouldn't be surprised of what a base:method with a set- compiler thingy would do to derived:method, they wouldn't be surprised that early binding (with COMPILE,) does the same. > As long as we only have those few words, rarely a problem (and that > problem is covered in the standard by disallowing ticking these words). We have more words where the standard disallows ticking, because of closely related problems. While it is pretty easy to explain why TO and S" are problematic, it is much more difficult to explain why EXIT and such are problematic. They shouldn't. Since you have argued that my DUP is just instrumentation and not changing compilation semantics: What's the case with Gforth's EXIT? It cleans up the locals stack. Is that changing the compilaton semantics or is it still doing the default compilation semantics? > But you suggest using SET-COMPILER instead of SET-COMPSEM not just for > these few words, but for defining words that might be used to define > many other words. I would not bet that nobody ever ticks the result > of such a defining word and never passes it to COMPILE,add. I'd like to have an obvious and straight-forward correspondence between interpretation, compilation, execution tokens and EXECUTE plus COMPILE,. That way it is pretty easy to describe what will happen in that case, and when it's obvious and easy, people understand the consequences. They might still want to COMPILE, the word, but they know what it does. > It certainly works for ordinary immediate words in all current Forth > systems. It works for user-defined words like that, but as you said, users shouldn't define such words. Leaves the system-defined words of that class. And there, it doesn't work. >>We can continue as we do now, and say this sort of stuff is simply not >>supposed to work portably. Or we say it's supposed to work in the next >>standard, and we then have to chose how. STATE-smart, SET-COMPILER or >>dual- xt are already implemented, and the three behave different. > > I think the way to go for the standard is to leave them as-is and turn > them into legacy (and eventually obsolete) with recognizers. For a > system, the right thing to do is still deciding at parse/FIND time, > not later; the other solutions are good enough, though, as long as > their use is kept to a minimum. That's where I disagree. Parse/FIND should not decide, it should just do the same thing regardless of state. What happens with the parsed/found stuff can depend on the state, but not earlier. The recognizer proposal is pretty clear about that: The recognizer is doing all the parsing and searching, but *not* doing any state-dependent stuff. The reason why a recognizer is much better than STATE-smart is actually that: It's stateless, always doing the same thing, predictable. >>That doesn't remove other dual-xt problems. > > What other problems? The ones you keep ignoring. Things like (not complete): * Words like FIND or recognizers shall not be STATE-dependent * Having three different tokenized representations of a word is overly complex * MY' example earlier on > I don't know what iForth actually uses. I would base optimization on > "COMPILE,", but basing it on compilation semantics is also possible > and does not lead to any problems except that you have to teach > [COMPILE] what is default compilation semantics and what is not; Or just don't support it any longer. It's obsolescent now. > No. My argument is that in the current standard the equivalence > between EXECUTE and COMPILE, holds for all xts you can get in a > standard program. If it doesn't, the system is non-standard. That must exclude xts you can get with FIND. The MY' using FIND can easily get such xts, and unlike ', there's no ambiguous condition on FIND. It will return an xt for every defined word (or two different, depending on state). > And it does hold. Nope. For all immediate compile-only xts found by FIND, which are specified in the standard only with execution semantics (like EXIT in Gforth), it doesn't. Current git-head Gforth has a set-compiler non-immediate EXIT, though, making it possible to COMPILE, the xt returned by FIND. >>If we want to make the behavior of use 2 portable across popular >>implementations, two out of three have to give in. > > Nobody has to give in. It works already. Including VFX? So then the SET-COMPILER approach is ok then? -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-04 16:58 +0000 |
| Message-ID | <2015May4.185829@mips.complang.tuwien.ac.at> |
| In reply to | #38799 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 25/04/2015 00:21, Bernd Paysan wrote:
>> 3. dual-xt has been critisized by Stephen Pelc, because it breaks the
>> conceptual unit of name and xt (where the xt is just a token for the name)
>
>I've not really been following the discussion about whether dual xt's
>are good or bad. But if you have a system where the xt is the address of
>a pointer that points to a small structure containing:
>1. a pointer to code implementing interpretation semantics
>2. a pointer to code implementing compilation semantics
>
>This is clearly less efficient as it has another level of indirection.
Well, about 0.5% of the executed primitives are EXECUTE in my
benchmarks <http://www.complang.tuwien.ac.at/forth/peep/sorted>, so
having one @ more in that case is not a big cost. And you can avoid
it with the following arrangement:
more header fields
compsem field
compile, field
native code
Disadvantage: code close to data; even if the data is just read, it
will slow down execution on old CPUs such as Pentium and AMD K6;
hopefully not in any newer ones. However, it is probably not frequent
to alternatingly run a word and, e.g., COMPILE, or NAME>COMP it, so
even on these CPUs, it should not be a big issue. The lower cache
utilization of the I and D caches are another disadvantage (which may
be more relevant than the cost of the additional @ for separated
headers).
>But ignoring that, if whatever uses the single xt chooses the correct
>implementation pointer do the problems associated with dual xts go away?
What problems?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | gwj.nexus@gmail.com |
|---|---|
| Date | 2015-05-05 11:24 -0700 |
| Message-ID | <8cf16d90-8de3-488a-88f1-52a7c2b61190@googlegroups.com> |
| In reply to | #38816 |
I should have made my question a bit more precise. I meant the problems with the xt that FIND returns, why S" and TO can't be ticked or postponed - generally everything that dual xts, SET-COMPILER and COMPSEM (or SET-COMPSEM) solve in their different ways. With the scheme I outlined there is only 1 xt so FIND should not be a problem. Bernd states that what remains is the difference between SET-COMPILER and SET-COMPSEM. Looking back through this discussion and a previous one, Stephen Pelc has given a description of SET-COMPILER but I can't find a description of SET-COMPSEM or COMPSEM, they just seem to have entered into the discussion without a clear idea of what they do or the problem they solve. Perhaps you can clarify this.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 13:13 +0000 |
| Message-ID | <2015May6.151313@mips.complang.tuwien.ac.at> |
| In reply to | #38847 |
gwj.nexus@gmail.com writes:
>Bernd states that what remains is the difference between SET-COMPILER and S=
>ET-COMPSEM. Looking back through this discussion and a previous one, Stephe=
>n Pelc has given a description of SET-COMPILER but I can't find a descripti=
>on of SET-COMPSEM or COMPSEM, they just seem to have entered into the discu=
>ssion without a clear idea of what they do or the problem they solve.
SET-COMPSEM changes the compilation semantics of a word, i.e., what
the text interpreter does when it encounters the word in compile
state, what NAME>COMPILE produces, and what FIND produces in compile
state.
The difference from SET-COMPILER is that the latter influences uses of
COMPILE, outside text interpreters, where COMPILE, is meant to be
equivalent to
: compile, postpone literal postpone execute ;
- 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-04-24 13:11 -0700 |
| Message-ID | <16284915-3f02-485e-971a-589e12664690@googlegroups.com> |
| In reply to | #38504 |
On Wednesday, April 22, 2015 at 8:42:17 AM UTC-7, Stephen Pelc wrote: > The permission to return different xts in interpretation and > compilation states was a concession to cmForth. Exploiting > this concession is itself a mistake im my opinion because it > reopens the box that xts were designed to keep shut. Earlier in this thread I said: On Wednesday, April 1, 2015 at 12:33:51 PM UTC-7, hughag...@gmail.com wrote: > On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote: > > I have been saying for a couple of years now that the ANS > > standard's definition of compilation and interpretation is > > incomprehensible for mere mortals such as myself. Every time > > I reread the standard on this topic, the more I believe that > > the standard's description of compilation and interpretation > > needs a complete rewrite. > > > > In essence, Forth is a language of simplicity. Complexity such > > as an optimising compiler is hidden. However, we now have a > > standard in which the classic Forth interpreter loop is > > broken according to some. We need to fix this by going back > > to basics rather than putting bandages on bad prose. > > I've been saying since 2009, which is more than a couple of years, that the solution is to define the language as a cross-compiler. In MFX I had HOST and TARG modes, so it was obvious which words were compile-time or run-time. Everything that runs at compile-time (either in the REPL or an immediate word used in a colon-word definition) had to have been defined in HOST mode. Everything that runs at run-time (on the MiniForth processor in the case of MFX) is defined in TARG mode. Also, every TARG mode word is defined twice --- we have the run-time version that executes on the target machine, and we have a compile-time version that is automatically generated as if it were hand-written in HOST mode and which compiles the TARG-mode version of itself --- these two words are in separate vocabularies and have distinct xt values, so there is no confusion between them. > > A cross-compiler is somewhat complicated to write, but using the cross-compiler is actually simpler for the user (presumably a "mere mortal") than using ANS-Forth is, because there is no confusion between "interpretation semantics" and "compilation semantics" as there is in ANS-Forth. You are using the term "semantics" that is defined as "the meaning of words" --- so it would make sense if two kinds of semantics (interpretation and compilation) are in distinct vocabularies, because they have different meanings --- but in ANS-Forth you have both kinds of semantics jumbled together in the same vocabulary (the FORTH-WORDLIST vocabulary), which is why it is confusing and will continue to be confusing indefinitely, and won't be cleared up by rewriting the ANS-Forth document as you suggest. > > The HOST mode words are written in a Forth running on the desktop-computer (I used UR/Forth for MFX, but am using VFX now). This host Forth still has the same problem as before, with compile-time words and run-time words jumbled together in the same vocabulary, so all that I've succeeded in doing is pushing the problem uphill, but the problem is still there. Pushing the problem uphill is actually quite helpful though, because it gets the problem out of the way for the common user. Programming is done at three levels, and the problem has been pushed all the way up to level-3, so most programmers never bump into the problem. These are the levels: > 1.) novice: Writes only in TARG mode. These guys typically came from a C programming background and don't know what "compile-time code" is --- this is common --- everybody starts here, and they can make a career out of writing application programs without learning any more than this. > 2.) intermediate: Writes in both TARG mode and HOST mode, but only writes HOST mode words that execute at run-time for HOST mode (which is compile-time for TARG words) --- this is rare --- it is only necessary to work at this level when adding any meta-compiling word to the cross-compiler. > 3.) advanced: Writes in both TARG mode and HOST mode, and writes HOST mode words that execute at compile-time for HOST mode (bumping into the aforementioned problem) --- this is extremely rare (I'm the only person who has ever done this) --- it is necessary when retargeting the cross-compiler for a new processor. > There are other problems in the gForth perspective, especially > in that you can't write a full Forth text interpreter in the > classical model. I think that gForth's perspective, which involves making it impossible to write an outer-interpreter (full Forth text interpreter), was done for the purpose of making it impossible to write a cross-compiler. You are the only person to benefit from this, because you make money selling cross-compilers and you don't want people to use gForth to write their own cross-compiler without paying you any money. But you now describe this as being a problem? A problem for who? It is not a problem for you, but it is only a problem for me. Since when are you concerned about helping me make money in competition with you? More likely, is that you paid the gForth developers (Anton Ertl and Bernd Payson) under the table to cripple gForth so that gForth couldn't be used for writing a cross-compiler by people like me. > I know that you and I are not going to agree on this topic, but > when you raise such issues, you should at least acknowledge > that there are differences of opinion on the topic. The Forth > 202x technical committee should start by having a long > discussion about what compilation in Forth actually involves. Differences of opinion? That is why I got kicked off the Forth-200x mailing list --- you didn't seem very interested in hearing about differences of opinion then. Anyway, it is not "impossible" --- I figured out a work-around for the problem, that uncripples both VFX and gForth despite the fact that VFX and gForth respond to the "ambiguous condition" differently from each other (it took me over 5 years to come up with this): : +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate : ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate : ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate : >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate : abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate : begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate : do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate : does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate : else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate : exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate : I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate : leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate : literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate : loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate : r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate : r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate : recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate : repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate : s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate : then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate : unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate : until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate : while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate : [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate : ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate : [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate : 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate : 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate : 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate : ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate : again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate : c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate : case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate : compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate : endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate : endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate : of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate : [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate : 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate : fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate : (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate : locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate : ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate : ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate : cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate : cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate : sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-25 21:05 -0700 |
| Message-ID | <a7370747-a015-4cd2-a68b-e4f5f03663b8@googlegroups.com> |
| In reply to | #38581 |
On Friday, April 24, 2015 at 1:11:06 PM UTC-7, hughag...@gmail.com wrote: > On Wednesday, April 22, 2015 at 8:42:17 AM UTC-7, Stephen Pelc wrote: > > There are other problems in the gForth perspective, especially > > in that you can't write a full Forth text interpreter in the > > classical model. > > I think that gForth's perspective, which involves making it impossible to write an outer-interpreter (full Forth text interpreter), was done for the purpose of making it impossible to write a cross-compiler. You are the only person to benefit from this, because you make money selling cross-compilers and you don't want people to use gForth to write their own cross-compiler without paying you any money. But you now describe this as being a problem? A problem for who? It is not a problem for you, but it is only a problem for me. Since when are you concerned about helping me make money in competition with you? More likely, is that you paid the gForth developers (Anton Ertl and Bernd Payson) under the table to cripple gForth so that gForth couldn't be used for writing a cross-compiler by people like me. I meant to say: "A problem for whom?" I apologize for the bad grammar.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-21 14:06 +0100 |
| Message-ID | <mh5hua$e5m$1@dont-email.me> |
| In reply to | #38433 |
on 21/04/2015 10:10:16, Mark Wills wrote: > > I don't see it as a conspiracy - it's just a bit of a mess. It's just > that some words don't do anything meaningful when not in compilation > state. IF is actually a good example. Executing IF at the command > line would cause some code to be compiled into memory, which is > meaningless, because you can't execute it. Hugh would rather lash out and attack people than address the source of the problem -- which is his behaviour. Only once he's fixed his rage and furstation can he possibly ever move on to work on a solution. For example, he was just plain wrong when he stated he could write an ANS Forth SYNONYM, but (as usual) I haven't seen him propose changes to the spec that would help. Just daft conspiracy theories that make him look like he's having a toddler temper tantrum. To the case in point. Worse than not only possibly compile some code into the code area, such a word might also put the control flow for ORIG on the stack. Or it might not, since to quote the spec; "Interpretation semantics for this word are undefined". That's undesirable to say the least. What is required is to eliminate STATE, find a replacement for FIND, and work on what is meant by interpret and compile and the definition of XT. There have been many threads about this on clf over the years. Sadly for us Hugh has just noticed this, and so CLF has to watch him throw a fit.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-22 20:05 -0700 |
| Message-ID | <ffc07822-7a0a-47e0-8d72-4aa6c5bb903d@googlegroups.com> |
| In reply to | #38433 |
On Tuesday, April 21, 2015 at 2:10:21 AM UTC-7, Mark Wills wrote:
> On Tuesday, 21 April 2015 07:21:06 UTC+1, hughag...@gmail.com wrote:
> > I figured out what is going on here.
> >
> > ANS-Forth has words that either lack an xt, or have an xt that aborts when executed. The purpose of this is to prevent common Forth programmers from writing cross-compilers. The outer interpreter in a Forth system is using a version of FIND that returns valid xt values for ALL words --- it wouldn't be able to work otherwise --- but the version of FIND that is provided to the common programmers has been sabotaged so that it doesn't return a valid xt value for some of the words. The result is that the common Forth programmer is not able to write an outer interpreter of his own. So, who wants to write an outer interpreter? Cross-compiler writers!
> >
> > The ANS-Forth standard was sabotaged to prevent common programmers from writing cross-compilers. This is because Forth Inc. and MPE make most of their money selling cross-compilers. I have really caught the ANS-Forth committee red-handed --- they sabotaged the Forth community on purpose --- they do not deserve any respect ever again from the Forth community!
>
> I don't see it as a conspiracy - it's just a bit of a mess. It's just
> that some words don't do anything meaningful when not in compilation
> state. IF is actually a good example. Executing IF at the command
> line would cause some code to be compiled into memory, which is
> meaningless, because you can't execute it. That's why VFX aborts if
> you attempt to execute IF when state=0. That's entitled behaviour,
> as the interpretation semantics of IF are undefined.
Mark, you totally failed to understand my example code:
: my-if [ ' if ] literal execute ; immediate ok
: ttt ( flag -- ) my-if ." true " else ." false " then ;
Err# -14 ERR: Attempt to interpret a compile only definition.
-> : ttt ( flag -- ) my-if ." true " else ." false " then ;
^
see my-if
MY-IF (is IMMEDIATE)
( 004C7A80 E89B23F4FF ) CALL 00409E20 IF
( 004C7A85 C3 ) NEXT,
( 6 bytes, 2 instructions )
ok
MY-IF is executing inside of a colon-word definition --- this is compilation mode --- it should have worked.
FIND has been sabotaged to provide a bad xt value for certain words; these include IF and everything else listed in the ANS-Forth manual to have "interpretation semantics undefined".
The outer interpreter in VFX uses a different version of FIND that is not sabotaged. This version of FIND provides a valid xt value for all words (including IF etc.). The outer interpreter gives this good xt value to EXECUTE (because it is an immediate) word, and it works correctly.
The FIND provided to the user has been sabotaged to provide xt values for these words (IF etc.) that will abort when given to EXECUTE. In the case of gForth, FIND itself aborts when it is told to look up the xt of these words (I noticed this in 2009 when my code aborted when it tried to tick semi-colon).
This is not "just a bit of a mess" --- this is cripple-ware --- VFX was crippled in such a way as to prevent the programmer from writing his own outer interpreter. Writing an outer interpreter is crucial to writing a cross-compiler. Stephen Pelc provided the VFX users with a crippled FIND that fails for certain words. He did this for the purpose of preventing his users from using VFX for writing a cross-compiler. This is because he makes most of his money selling cross-compilers, and he doesn't want people to use VFX to compete against him.
I defeated this sabotage however:
: if
state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate
: my-if [ ' if ] literal execute ; immediate ok
: ttt ( flag -- ) my-if ." true" else ." false" then ; ok
1 ttt true ok
0 ttt false ok
Now FIND provides a valid xt for IF --- this is the key to using VFX to write an outer interpreter --- this is how Stephen Pelc's cripple-ware can be uncrippled so that VFX can be used for writing a cross-compiler in competition with MPE.
I don't really blame Stephen Pelc for selling cripple-ware. He is in the business of selling cross-compilers, and he doesn't want people to use VFX to write their own cross-compiler in competition with him.
I do blame Anton Ertl for whitewashing this sabotage. And I blame the ANS-Forth committee for saying that a sabotaged FIND is actually standard. This is grossly dishonest. All that pseudo-intellectual blather that Anton Ertl was giving me, to the effect that I shouldn't expect FIND to work for all the words (IF etc.), was whitewash. He is lying. He is protecting Forth Inc. and MPE, by lying to the Forth community. I think this is really the end of Anton Ertl's career. Nobody will ever trust him again. He is just a stooge of Forth Inc. and MPE --- he is lying to the Forth community --- he doesn't deserve any respect at all.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-23 05:57 +0000 |
| Message-ID | <2015Apr23.075727@mips.complang.tuwien.ac.at> |
| In reply to | #38523 |
hughaguilar96@gmail.com writes:
>Mark, you totally failed to understand my example code:
>
>: my-if [ ' if ] literal execute ; immediate ok=20
>: ttt ( flag -- ) my-if ." true " else ." false " then ;=20
>Err# -14 ERR: Attempt to interpret a compile only definition.=20
> -> : ttt ( flag -- ) my-if ." true " else ." false " then ;=20
> ^=20
>see my-if=20
>MY-IF (is IMMEDIATE)=20
>( 004C7A80 E89B23F4FF ) CALL 00409E20 IF=20
>( 004C7A85 C3 ) NEXT,=20
>( 6 bytes, 2 instructions )=20
> ok=20
>
>MY-IF is executing inside of a colon-word definition --- this is compilatio=
>n mode --- it should have worked.
>
>FIND has been sabotaged to provide a bad xt value for certain words; these =
>include IF and everything else listed in the ANS-Forth manual to have "inte=
>rpretation semantics undefined".=20
>
>The outer interpreter in VFX uses a different version of FIND that is not s=
>abotaged. This version of FIND provides a valid xt value for all words (inc=
>luding IF etc.). The outer interpreter gives this good xt value to EXECUTE =
>(because it is an immediate) word, and it works correctly.=20
Let's try your example the VFX way:
: my-if [ ' if ] literal compile, ; immediate ok
: ttt ( flag -- ) my-if ." true " else ." false " then ; ok
1 ttt true ok
0 ttt false ok
When I SEE INTERPRET, it says:
( 08058F9C E80FBDFFFF ) CALL 08054CB0 FIND
Different from the FIND you get?
' find hex . 8054CB0 ok
Apparently not.
What happens is that FIND in the text interpreter produces this xt for
FIND and reports that it is *not* immediate, the text interpreter then
calls "COMPILE,", and that then performs the compilation semantics.
Unusual, but it works for text-interpreting.
>The FIND provided to the user has been sabotaged to provide xt values for t=
>hese words (IF etc.) that will abort when given to EXECUTE. In the case of =
>gForth, FIND itself aborts when it is told to look up the xt of these words=
> (I noticed this in 2009 when my code aborted when it tried to tick semi-co=
>lon).
: c-if c" if" ; ok
c-if find . . 1 140737331022592 ok
c-if find . execute 1
:4: Interpreting a compile-only word
c-if find . >>>execute<<<
So FIND does not abort, reports an xt for the interpretation semantics
and an immediate word and a text interpreter using FIND would then
EXECUTE the xt, and would get the error at that point.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-23 10:50 +0000 |
| Message-ID | <5538ce3b.163707995@news.eternal-september.org> |
| In reply to | #38523 |
On Wed, 22 Apr 2015 20:05:28 -0700 (PDT), hughaguilar96@gmail.com wrote: >The outer interpreter in VFX uses a different version of FIND that is not s= >abotaged. Rubbish. 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-24 11:59 -0700 |
| Message-ID | <f438ffbd-adf4-4ada-b244-240ed3d673ff@googlegroups.com> |
| In reply to | #38531 |
On Thursday, April 23, 2015 at 3:50:14 AM UTC-7, Stephen Pelc wrote: > On Wed, 22 Apr 2015 20:05:28 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >The outer interpreter in VFX uses a different version of FIND that is not s= > >abotaged. > > Rubbish. > > Stephen I conflated VFX and gForth, which was incorrect. It is gForth that provides the users with a sabotaged FIND that aborts for certain words (there must be a fully functional FIND used internally by the outer-interpreter however, in order for the outer-interpreter to work). In gForth, FIND special-cases certain words. In VFX, COMPILE, special-cases those words. Your FIND provides an xt that can't be executed --- this is despite the fact that we are supposed to be able to EXECUTE an xt (xt means: "execution token"). Your COMPILE, is special-casing these xt values, rather than compile them --- so you are exposing the implementation of your compiler to the user --- this is why my example (with MY-IF earlier) failed to work under VFX when it should have worked. The words being special-cased are those for which: "interpretation semantics for this word are undefined." Weirdly enough, you don't consistently special-case these. For example, IF is non-immediate but semicolon is immediate, so you have special-cased IF but not semicolon, although they both fall under the "ambiguous conditions" (section 4.1.2): "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 think that both VFX and gForth are special-casing certain fundamental words in order to make it difficult for the user to write a cross-compiler. Both VFX and gForth can be defeated in their effort at obfuscation however. With the following code, we are put back on familiar ground (FIG-Forth, Forth-79 and Forth-83) again and everything once again works the way that it should. : +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate : ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate : ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate : >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate : abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate : begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate : do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate : does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate : else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate : exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate : I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate : leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate : literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate : loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate : r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate : r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate : recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate : repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate : s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate : then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate : unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate : until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate : while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate : [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate : ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate : [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate : 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate : 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate : 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate : ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate : again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate : c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate : case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate : compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate : endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate : endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate : of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate : [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate : 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate : fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate : (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate : locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate : ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate : ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate : cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate : cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate : sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-05-12 23:18 +0000 |
| Message-ID | <miu1on$g67$1@dont-email.me> |
| In reply to | #38523 |
hughaguilar96@gmail.com wrote: > All that pseudo-intellectual blather that Anton > Ertl was giving me, to the effect that I shouldn't > expect FIND to work for all the words (IF etc.), > was whitewash. Did FIND work for all words in some pre-ANS Forths? Specifically, did it work under UR/Forth?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-12 20:24 -0700 |
| Message-ID | <9b9fc06c-bda5-4e0a-acb1-6ccc7593b8e0@googlegroups.com> |
| In reply to | #39047 |
On Tuesday, May 12, 2015 at 4:19:56 PM UTC-7, WJ wrote: > hughaguilar96@gmail.com wrote: > > > All that pseudo-intellectual blather that Anton > > Ertl was giving me, to the effect that I shouldn't > > expect FIND to work for all the words (IF etc.), > > was whitewash. > > Did FIND work for all words in some pre-ANS Forths? > Specifically, did it work under UR/Forth? FIND always worked on all words. Also, the xt (called a cfa then) could be given to EXECUTE or COMPILE, and it would work. An xt for an immediate word should only be executed in or compiled into another immediate word --- this is easy to ensure however, because FIND tells you if the xt it is returning is of an immediate or non-immediate word --- most immediate words (IF, semicolon, etc.) will abort with an error message if used in interpretation mode, because that makes no sense and is an error. My SYNONYM SYNONYM-FAST and ALIAS would have worked fine without the disambiguifiers --- now they need the disambiguifiers to work, otherwise they abort with baffling error messages. All of ANS-Forth's ambiguity is gratuitous --- none of that existed in Forth-83 (UR/Forth was Forth-83; Ray Duncan gave up on Forth when ANS-Forth became the standard) --- there is no positive benefit to ambiguity. The fact that my disambiguifiers get rid of the ambiguity shows that the ambiguity is artificially imposed and is not inherent --- it is sabotage that can be fixed --- my disambiguifiers "jail-break" FIND from its artificial restrictions.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-24 08:56 -1000 |
| Message-ID | <H-udnfPCUtdnDKfInZ2dnUU7-cWdnZ2d@supernews.com> |
| In reply to | #37804 |
On 4/1/15 1:26 AM, Stephen Pelc wrote: ... > > I have been saying for a couple of years now that the ANS > standard's definition of compilation and interpretation is > incomprehensible for mere mortals such as myself. Every time > I reread the standard on this topic, the more I believe that > the standard's description of compilation and interpretation > needs a complete rewrite. > > In essence, Forth is a language of simplicity. Complexity such > as an optimising compiler is hidden. However, we now have a > standard in which the classic Forth interpreter loop is > broken according to some. We need to fix this by going back > to basics rather than putting bandages on bad prose. I agree that the description is pretty arcane, and encourage you to have a crack at it. Describing compilation and interpretation with precision but without constraining implementation is harder than it looks, and quite a lot of effort was put into it by a bunch of smart people, with the current result. I look forward to reading your version :-) 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-04-24 12:09 -0700 |
| Message-ID | <497a83f3-827b-4fe8-a04d-67079787bfac@googlegroups.com> |
| In reply to | #38576 |
On Friday, April 24, 2015 at 11:56:59 AM UTC-7, Elizabeth D. Rather wrote:
> On 4/1/15 1:26 AM, Stephen Pelc wrote:
> ...
> >
> > I have been saying for a couple of years now that the ANS
> > standard's definition of compilation and interpretation is
> > incomprehensible for mere mortals such as myself. Every time
> > I reread the standard on this topic, the more I believe that
> > the standard's description of compilation and interpretation
> > needs a complete rewrite.
> >
> > In essence, Forth is a language of simplicity. Complexity such
> > as an optimising compiler is hidden. However, we now have a
> > standard in which the classic Forth interpreter loop is
> > broken according to some. We need to fix this by going back
> > to basics rather than putting bandages on bad prose.
>
> I agree that the description is pretty arcane, and encourage you to have
> a crack at it. Describing compilation and interpretation with precision
> but without constraining implementation is harder than it looks, and
> quite a lot of effort was put into it by a bunch of smart people, with
> the current result.
>
> I look forward to reading your version :-)
>
> Cheers,
> Elizabeth
I look forward to you shutting your stupid mouth.
Your "bunch of smart people" on the ANS-Forth committee gave us the following as our current result:
3.4.4 Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or more of the following actions:
- ignore and continue;
- display a message;
- execute a particular word;
- set interpretation state and begin text interpretation;
- take other implementation-defined actions;
- take implementation-dependent actions.
The response to a particular ambiguous condition need not be the same under all circumstances.
Anyway, I have defeated your effort at making FIND ambiguous. This ANS-Forth code disambiguifies the situation:
: +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate
: ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate
: ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate
: >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate
: abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate
: begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate
: do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate
: does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate
: else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate
: exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate
: I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate
: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate
: J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate
: leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate
: literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate
: loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate
: postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate
: r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate
: r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate
: recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate
: repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate
: s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate
: then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate
: unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate
: until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate
: while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate
: [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate
: ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate
: [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate
: 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate
: 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate
: 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate
: ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate
: again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate
: c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate
: case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate
: compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate
: endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate
: endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate
: of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate
: [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate
: 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate
: fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate
: (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate
: locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate
: ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate
: ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate
: cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate
: cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate
: sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-24 22:29 +0100 |
| Message-ID | <mheci8$rt8$1@dont-email.me> |
| In reply to | #38579 |
on 24/04/2015 20:09:27, hurge wrote: > > I look forward to you shutting your stupid mouth. I look forward to hearing that you've grown up.
[toc] | [prev] | [next] | [standalone]
Page 23 of 26 — ← Prev page 1 … 21 22 [23] 24 25 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web