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 22 of 26 — ← Prev page 1 … 20 21 [22] 23 24 … 26 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-22 16:43 +0000 |
| Message-ID | <2015Apr22.184328@mips.complang.tuwien.ac.at> |
| In reply to | #38504 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Wed, 22 Apr 2015 14:06:16 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>VFX has only one xt for every word. EXECUTEing that xt produces the
>>interpretation semantics of the word, while COMPILE,in it produces the
>>compilation semantics. That's the wrong way to do it, because
>>COMPILE, is no longer equivalent to
>>
>>: compile, postpone literal postpone execute ;
>>
>>but the cases where the difference matters are very special and
>>contrived and non-standard until now. If we ever standardized COMP:
>>or somesuch, the difference would matter.
>
>The ANS specification uses an xt as an opaque type that is the single
>point of reference to a word. It was designed to avoid the raft of
>dictionary navigation words required for effective use of FIG and
>Forth-83 systems.
>
>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.
Abolish >BODY now! Just joking.
While the fig-Forth way to navigate in a header is messy, it does not
cause problems comparable to those of STATE-smart words (i.e., bugs
that appear far from the origin).
But actually comparing the issue to fig-Forth header navigation is a
red herring in several ways:
1) fig-Forth did not solve the problem of STATE-smart words.
2) Forth-94 does not provide the capabilities that the fig-Forth
header words provide. Link field, name field, code field, parameter
field? The only part of that that Forth-94 has to get to what
fig-Forth called the parameter field, and Forth-94 contains an extra
word for that: >BODY. If they really wanted to avoid all that
navigation, they would have eliminated >BODY, too, and used the body
address as the single point of reference.
We have the capabilities partly in Forth-2012: TRAVERSE-WORDLIST
provides part of what could be done with the link field, NAME>STRING
gives us the name field, NAME>INT (and NAME>COMP) correspond to
getting to the code field.
Anyway, the origin of the problem is words like S", TO, IS, and
ACTION-OF. When they are text-interpreted, you want them to do the
parsing at text-interpretation time, and then something at run-time
(and maybe some storage in between). That does not fit the classical
Forth model of having a single xt.
People have worked around that with STATE-smart words, but that
produces state-dependent behaviour when these words are ticked or
POSTPONEd, which leads to unintended behaviour in some cases far from
the cause of the problem.
In Gforth these words have one xt representing the interpretation
semantics and one xt for compilation semantics.
In VFX you solve that problem by noticing that the classical text
interpreter COMPILE,s words not marked as immediate in compile state,
and EXECUTEs them in interpretation state.
So you hang the two semantics of words like S" on one xt, the
interpretation semantics is performed by EXECUTE, the compilation
semantics by COMPILE,. That's a good idea for words with default
compilation semantics (i.e., normal words like +), but not for words
like S", because it breaks the relation between EXECUTE and COMPILE,
i.e., COMPILE, being equivalent to
: compile, postpone literal postpone execute ;
This equivalence is used in, e.g., various OOF packages (dynamic
binding EXECUTEs, early binding COMPILE,s), but fortunately you don't
use the xt of S" etc. in that context, and ticking S" is rare in
general, so the problem does not occur in practice for now.
The long-term solution IMO is to get rid of words like S", i.e., have
only words with one semantics. For replacing these parsing words
recognizers may be the solution.
>There are other problems in the gForth perspective, especially
>in that you can't write a full Forth text interpreter in the
>classical model.
Incorrect and unsubstantiated claims...is your name Hugh Aguilar?
>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.
I rely on you making that point:-).
>The Forth
>202x technical committee should start by having a long
>discussion about what compilation in Forth actually involves.
Fine with me, although somewhat sceptical given the way earlier
discussions have gone.
- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-24 05:35 +0200 |
| Message-ID | <mhcdl1$qh$1@dont-email.me> |
| In reply to | #38510 |
Anton Ertl wrote: > So you hang the two semantics of words like S" on one xt, the > interpretation semantics is performed by EXECUTE, the compilation > semantics by COMPILE,. That's a good idea for words with default > compilation semantics (i.e., normal words like +), but not for words > like S", because it breaks the relation between EXECUTE and COMPILE, > i.e., COMPILE, being equivalent to > > : compile, postpone literal postpone execute ; IIRC, the result of our last discussion was that this equivalence doesn't hold for compile-only words, because you aren't allowed to tick them. As you derive this equivalence from ' foo execute = interpretation semantics. If you can't tick foo in a standard way, ' foo execute = undefined; and that certainly beaks the compile, equivalence, too. Neither does it apply to words with special compilation semantics like S" or TO, because we added these words to the list of "untickable words". Leaves normal and deliberately immediate words like ( or \ for which this equivalence can hold. FIND can return an xt for an untickable word, but that xt is not necessarily the one for which the ' foo execute equivalence holds, so the compile,- equivalence also can't work. If you have problems remembering the discussion, I've video-taped it. > This equivalence is used in, e.g., various OOF packages (dynamic > binding EXECUTEs, early binding COMPILE,s), but fortunately you don't > use the xt of S" etc. in that context, and ticking S" is rare in > general, so the problem does not occur in practice for now. And we have managed to make sure the problem can't occur in a standard program for the Forth-2012 standard. By making all those words that won't hold that equivalence untickable. As I'm fully for tightening up the spec, we can tighten it up differently. Usually, thise OOF package use :NONAME xts for method implementations, and :NONAME-xts work. People who use SET-COMPILER on their xts create non- standard programs, and they probably know what they do (different early/late binding behavior could sometimes be deliberate). > The long-term solution IMO is to get rid of words like S", i.e., have > only words with one semantics. For replacing these parsing words > recognizers may be the solution. That's indeed one possible solution. >>There are other problems in the gForth perspective, especially >>in that you can't write a full Forth text interpreter in the >>classical model. > > Incorrect and unsubstantiated claims...is your name Hugh Aguilar? Indeed, you can write a classical text interpretern in Gforth, the same way as in fig-Forth, VFX or whatever. The non-classical magic of Gforth's approach happens in FIND, the non-classical magic of VFX's approach happens in COMPILE,. >>The Forth >>202x technical committee should start by having a long >>discussion about what compilation in Forth actually involves. > > Fine with me, although somewhat sceptical given the way earlier > discussions have gone. The last discussion was pretty long ;-). -- 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-04-24 11:22 +0000 |
| Message-ID | <2015Apr24.132234@mips.complang.tuwien.ac.at> |
| In reply to | #38552 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> So you hang the two semantics of words like S" on one xt, the
>> interpretation semantics is performed by EXECUTE, the compilation
>> semantics by COMPILE,. That's a good idea for words with default
>> compilation semantics (i.e., normal words like +), but not for words
>> like S", because it breaks the relation between EXECUTE and COMPILE,
>> i.e., COMPILE, being equivalent to
>>
>> : compile, postpone literal postpone execute ;
>
>IIRC, the result of our last discussion was that this equivalence doesn't
>hold for compile-only words, because you aren't allowed to tick them. As
>you derive this equivalence from ' foo execute = interpretation semantics.
>If you can't tick foo in a standard way, ' foo execute = undefined; and that
>certainly beaks the compile, equivalence, too.
Sure, if you like languages with undefined behaviour, one can argue
that way.
OTOH, if you look at how COMPILE, is used, there are two ways to use
it:
1) Use it in text interpreters.
2) Use it to append the same semantics to a definition that EXECUTE
executes.
Both uses occur in programs that are out there, so we should implement
our systems such that they both work.
One may argue that not all xts tend to be used with use 2 (also with
use 1, BTW; consider xts coming from :NONAME words), so it's good
enough if these xts don't behave in a way compatible with use 2. In
particular, as I mentioned above, the (single) xt of S" in VFX does
not work properly with use 2.
One may consider that good enough as long as nobody uses it, so no
customer complains, but one should be aware that it is a good-enough
solution, not the right thing (and good-enough more in the Washington
(Redmond) style, not as in the New Jersey (Murray Hill) style that
Gabriel's paper compared the MIT approach to).
Anyway, just because no customer has complained to Stephen Pelc yet
does not mean that there is no code out there that uses COMPILE, in
use pattern 2, with an xt where VFX breaks the pattern. Nobody
complained to Stephen Pelc about VFX breaking return-address
manipulations until you came along.
>> This equivalence is used in, e.g., various OOF packages (dynamic
>> binding EXECUTEs, early binding COMPILE,s), but fortunately you don't
>> use the xt of S" etc. in that context, and ticking S" is rare in
>> general, so the problem does not occur in practice for now.
>
>And we have managed to make sure the problem can't occur in a standard
>program for the Forth-2012 standard. By making all those words that won't
>hold that equivalence untickable. As I'm fully for tightening up the spec,
>we can tighten it up differently.
Tightening it up in a way that would destandardize the existing uses
is a no-go.
I also don't see a good way to tighten it up in a way that would allow
VFXs current implementation.
>Usually, thise OOF package use :NONAME xts for method implementations, and
>:NONAME-xts work. People who use SET-COMPILER on their xts create non-
>standard programs, and they probably know what they do (different early/late
>binding behavior could sometimes be deliberate).
Deliberate mistakes, like STATE-smart words. Looks cute at first, and
the problems are only seen far later, perhaps by someone else.
So it seems that you suggest that SET-COMPILER and the like will never
be standardized. Fine with me.
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-24 11:18 -0700 |
| Message-ID | <8073a6d0-8f22-487c-ad0a-0db91a50e567@googlegroups.com> |
| In reply to | #38559 |
On Friday, April 24, 2015 at 5:17:04 AM UTC-7, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >Anton Ertl wrote: > > > >> So you hang the two semantics of words like S" on one xt, the > >> interpretation semantics is performed by EXECUTE, the compilation > >> semantics by COMPILE,. That's a good idea for words with default > >> compilation semantics (i.e., normal words like +), but not for words > >> like S", because it breaks the relation between EXECUTE and COMPILE, > >> i.e., COMPILE, being equivalent to > >> > >> : compile, postpone literal postpone execute ; > > > >IIRC, the result of our last discussion was that this equivalence doesn't > >hold for compile-only words, because you aren't allowed to tick them. As > >you derive this equivalence from ' foo execute = interpretation semantics. > >If you can't tick foo in a standard way, ' foo execute = undefined; and that > >certainly beaks the compile, equivalence, too. > > Sure, if you like languages with undefined behaviour, one can argue > that way. > > OTOH, if you look at how COMPILE, is used, there are two ways to use > it: > > 1) Use it in text interpreters. > > 2) Use it to append the same semantics to a definition that EXECUTE > executes. > > Both uses occur in programs that are out there, so we should implement > our systems such that they both work. > > One may argue that not all xts tend to be used with use 2 (also with > use 1, BTW; consider xts coming from :NONAME words), so it's good > enough if these xts don't behave in a way compatible with use 2. In > particular, as I mentioned above, the (single) xt of S" in VFX does > not work properly with use 2. > > One may consider that good enough as long as nobody uses it, so no > customer complains, but one should be aware that it is a good-enough > solution, not the right thing (and good-enough more in the Washington > (Redmond) style, not as in the New Jersey (Murray Hill) style that > Gabriel's paper compared the MIT approach to). > > Anyway, just because no customer has complained to Stephen Pelc yet > does not mean that there is no code out there that uses COMPILE, in > use pattern 2, with an xt where VFX breaks the pattern. Nobody > complained to Stephen Pelc about VFX breaking return-address > manipulations until you came along. > > >> This equivalence is used in, e.g., various OOF packages (dynamic > >> binding EXECUTEs, early binding COMPILE,s), but fortunately you don't > >> use the xt of S" etc. in that context, and ticking S" is rare in > >> general, so the problem does not occur in practice for now. > > > >And we have managed to make sure the problem can't occur in a standard > >program for the Forth-2012 standard. By making all those words that won't > >hold that equivalence untickable. As I'm fully for tightening up the spec, > >we can tighten it up differently. > > Tightening it up in a way that would destandardize the existing uses > is a no-go. You two, with your talk about "untickable words," are purposely obfuscating Forth. You are trying to baffle the Forth users (you had me pretty well baffled starting in 2009 and continuing until just now in this thread when I figured out the solution). The ANS-Forth document has a section (4.1.2) with the ominous heading: "Ambiguous Conditions." One of the many ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." In gForth this was interpreted to mean that it is ANS-Forth legal for FIND and tick to abort when given a word for which: "Interpretation semantics for this word are undefined." I think that this was done for the purpose of preventing the user from writing an outer-interpreter, and this was done for the purpose of preventing the user from writing a cross-compiler. > I also don't see a good way to tighten it up in a way that would allow > VFXs current implementation. You are playing dumb in order to make the readers believe that it is legal in ANS-Forth for FIND and tick to abort for certain words (gForth) or for certain words to have an xt (execution token) that can't be executed (VFX), and you are doing this for the purpose of making the readers believe that they can't write a cross-compiler in ANS-Forth. I already gave you the solution (works for both VFX and gForth, despite the fact that these compilers are incompatible): : +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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-25 01:21 +0200 |
| Message-ID | <mhej4f$mkg$1@dont-email.me> |
| In reply to | #38559 |
Anton Ertl wrote: >>IIRC, the result of our last discussion was that this equivalence doesn't >>hold for compile-only words, because you aren't allowed to tick them. As >>you derive this equivalence from ' foo execute = interpretation semantics. >>If you can't tick foo in a standard way, ' foo execute = undefined; and >>that certainly beaks the compile, equivalence, too. > > Sure, if you like languages with undefined behaviour, one can argue > that way. I'm against languages with undefined behavior, but the defined behavior should actually be reasonable and corresponding to major implementations. The way the current standard specifies compilation and interpretation, with all the consequences for FIND (may be state smart), COMPILE, and others, represents competing implementation practices from 1994, including cmForth, and does not provide a standard solution to words like S" (apart from state- smart). > OTOH, if you look at how COMPILE, is used, there are two ways to use > it: > > 1) Use it in text interpreters. > > 2) Use it to append the same semantics to a definition that EXECUTE > executes. > > Both uses occur in programs that are out there, so we should implement > our systems such that they both work. Yes, as long as there aren't conflicts with exiting usage. ' S" COMPILE, results in various different behaviours depending on the implementation of S". This is not hypothetically undefined, this is currently non-portable. The three major implementers of the Forth 2012 committee have three different ways to implement S": SwiftForth has it state-smart, VFX has it with a smart COMPILE, and Gforth uses a dual-xt approach. > One may argue that not all xts tend to be used with use 2 (also with > use 1, BTW; consider xts coming from :NONAME words), so it's good > enough if these xts don't behave in a way compatible with use 2. In > particular, as I mentioned above, the (single) xt of S" in VFX does > not work properly with use 2. The single xt of S" in Swiftforth doesn't, either, but for different reasons (it's a STATE-smart word). IMHO your example is a straw man right now, because there's no consensus how to implement these words, and therefore, any program making assumptions about these words is right now really non- portable. Not just potentially non-portable when someone starts writing a compiler with the intention to break such a program. It doesn't work right now, and if we want to reduce that portability issue (I think the problems with these words are a portability issue), we can only do so by tightening up the spec. And this will break at least the behavior of two out of three current implementation choices (supposing we will choose one of the existing solutions). So far, all three existing approaches face critics: 1. STATE-smart has been vocally critisized by you 2. smart COMPILE, has been critisized by you 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) E.g ' S" >NAME .NAME works fine and as expected in VFX and SwiftForth, while Gforth has no displayable name both for ' S" and COMP' S" DROP. > One may consider that good enough as long as nobody uses it, so no > customer complains, but one should be aware that it is a good-enough > solution, not the right thing (and good-enough more in the Washington > (Redmond) style, not as in the New Jersey (Murray Hill) style that > Gabriel's paper compared the MIT approach to). If we do "the right thing", from the currently three different approaches at words with special compiliation semantics, at most one can survive. I.e. we have the choice to keep things undefined, so that people's non-portable programs continue to work on their platform, or we potentially break some code. There's no wash me but don't get me wet here. We also can't just create a new word for the smart COMPILE,, because that one would break existing code, too. > Anyway, just because no customer has complained to Stephen Pelc yet > does not mean that there is no code out there that uses COMPILE, in > use pattern 2, with an xt where VFX breaks the pattern. Nobody > complained to Stephen Pelc about VFX breaking return-address > manipulations until you came along. Maybe. You had raised some theoretical concerns about his source inliner. The inliner broke hard, and that was completely different from what your concerns were. The smart COMPILE, did not cause any problems with my code, even though I'm exactly doing this case 2) thing, which is the case where your concerns are really really big. And I'm not the only one; IIRC, MPE maintains 5 different OOP packages (much to their dismay), all with the same potential issue. >>> This equivalence is used in, e.g., various OOF packages (dynamic >>> binding EXECUTEs, early binding COMPILE,s), but fortunately you don't >>> use the xt of S" etc. in that context, and ticking S" is rare in >>> general, so the problem does not occur in practice for now. >> >>And we have managed to make sure the problem can't occur in a standard >>program for the Forth-2012 standard. By making all those words that won't >>hold that equivalence untickable. As I'm fully for tightening up the >>spec, we can tighten it up differently. > > Tightening it up in a way that would destandardize the existing uses > is a no-go. Well, the actual really existing use, destandardizing straw men is completely ok. I don't want to break real existing code. > I also don't see a good way to tighten it up in a way that would allow > VFXs current implementation. We already concluded that VFXs current implementation is standard, so it's allowed - if you have problems remembering, I still have the recordings. The question whether we tighten it towards this approach therefore is not to allow it, but if consensus emerges. One vote against would still be a rough consensus. >>Usually, thise OOF package use :NONAME xts for method implementations, and >>:NONAME-xts work. People who use SET-COMPILER on their xts create non- >>standard programs, and they probably know what they do (different >>early/late binding behavior could sometimes be deliberate). > > Deliberate mistakes, like STATE-smart words. Looks cute at first, and > the problems are only seen far later, perhaps by someone else. Forth is not a nanny language. There are features which can cause problems if not used right. There are, on the other hand, features like STATE+IMMEDIATE, which are problematic. > So it seems that you suggest that SET-COMPILER and the like will never > be standardized. Fine with me. I don't suggest this. The question of SET-COMPILER is about emerging consensus. At the moment, we only have a very inadequate standard mean for users to write their own words with special compilation semantics, and that one must go. I won't support dual-xt. That was an implementation option in ANS Forth for cmForth, and because it didn't receive enough review, you figured out that it is the only way to implement these words in ANS Forth. We did that review with Forth-2012, and it's no longer true, in Forth-2012, all three current practice implementations (STATE-smart, dual-xt, SET-COMPILER) are legal; and that was the original intention for ANS Forth, too. If a consensus emerges, we can narrow that down to one option. -- 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-04-25 16:49 +0000 |
| Message-ID | <2015Apr25.184929@mips.complang.tuwien.ac.at> |
| In reply to | #38586 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> OTOH, if you look at how COMPILE, is used, there are two ways to use
>> it:
>>
>> 1) Use it in text interpreters.
>>
>> 2) Use it to append the same semantics to a definition that EXECUTE
>> executes.
>>
>> Both uses occur in programs that are out there, so we should implement
>> our systems such that they both work.
>
>Yes, as long as there aren't conflicts with exiting usage. ' S" COMPILE,
>results in various different behaviours depending on the implementation of
>S". This is not hypothetically undefined, this is currently non-portable.
>The three major implementers of the Forth 2012 committee have three
>different ways to implement S": SwiftForth has it state-smart, VFX has it
>with a smart COMPILE, and Gforth uses a dual-xt approach.
If you want to tighten the standard to allow ' S", SwiftForth and VFX
do it wrongly.
>> One may argue that not all xts tend to be used with use 2 (also with
>> use 1, BTW; consider xts coming from :NONAME words), so it's good
>> enough if these xts don't behave in a way compatible with use 2. In
>> particular, as I mentioned above, the (single) xt of S" in VFX does
>> not work properly with use 2.
>
>The single xt of S" in Swiftforth doesn't, either, but for different reasons
>(it's a STATE-smart word).
COMPILE, certainly works right on SwiftForth. STATE-smartness causes
problems later, however.
>IMHO your example is a straw man right now,
>because there's no consensus how to implement these words, and therefore,
>any program making assumptions about these words is right now really non-
>portable. Not just potentially non-portable when someone starts writing a
>compiler with the intention to break such a program.
So systems have bugs. We papered over these bugs by making ' S" etc.
non-standard, and we can leave it at that. But somebody asked for a
discussion. If you want to tighten the standard and want to allow ' S"
in standard programs, the result should work in the use 2 of COMPILE,.
>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)
There is no such unity in the standard, as evidenced by the definition
of FIND. One may find having several xts inelegant, but as long as we
have words like S", it's the way to go.
>E.g ' S" >NAME .NAME works fine and as expected in VFX and SwiftForth, while
>Gforth has no displayable name both for ' S" and COMP' S" DROP.
That is easy to fix.
>If we do "the right thing", from the currently three different approaches at
>words with special compiliation semantics, at most one can survive. I.e. we
>have the choice to keep things undefined, so that people's non-portable
>programs continue to work on their platform, or we potentially break some
>code. There's no wash me but don't get me wet here. We also can't just
>create a new word for the smart COMPILE,, because that one would break
>existing code, too.
Wasn't it you who claimed that nobody uses ' S" etc., so not doing the
right thing for ' S" etc. is ok? If you are right, no code will
break.
>The smart COMPILE, did not cause any problems with my code, even though I'm
>exactly doing this case 2) thing, which is the case where your concerns are
>really really big.
Well, STATE-smartness also did not cause problems for you, so it's not
like you detect all problems. But yes, as long as it's limited to the
standard words, I don't expect problems.
>> Tightening it up in a way that would destandardize the existing uses
>> is a no-go.
>
>Well, the actual really existing use, destandardizing straw men is
>completely ok.
We also have to take the conceptual burden on the programmers into
account. If you "tighten" the xt, EXECUTE and COMPILE, such that use
2 works for some xts, but not for others (and probably without a test
whether an xt belongs to the use-2 class or not), the standard becomes
messy.
May be a better tightening idea is to require ' S" etc. to produce an
error, in preparation for phasing S" etc. out. I have no good idea
how to tighten FIND, though.
>> I also don't see a good way to tighten it up in a way that would allow
>> VFXs current implementation.
>
>We already concluded that VFXs current implementation is standard, so it's
>allowed - if you have problems remembering, I still have the recordings.
>The question whether we tighten it towards this approach therefore is not to
>allow it, but if consensus emerges.
Tightening towards VFX's current implementation is not a good way to
tighten the standard, as it outlaws use 2.
>>>Usually, thise OOF package use :NONAME xts for method implementations, and
>>>:NONAME-xts work. People who use SET-COMPILER on their xts create non-
>>>standard programs, and they probably know what they do (different
>>>early/late binding behavior could sometimes be deliberate).
>>
>> Deliberate mistakes, like STATE-smart words. Looks cute at first, and
>> the problems are only seen far later, perhaps by someone else.
>
>Forth is not a nanny language. There are features which can cause problems
>if not used right. There are, on the other hand, features like
>STATE+IMMEDIATE, which are problematic.
As are different early/late binding semantics.
>> So it seems that you suggest that SET-COMPILER and the like will never
>> be standardized. Fine with me.
>
>I don't suggest this. The question of SET-COMPILER is about emerging
>consensus. At the moment, we only have a very inadequate standard mean for
>users to write their own words with special compilation semantics, and that
>one must go.
We have no standard for that.
>I won't support dual-xt.
"One vote against would still be a rough consensus."
>That was an implementation option in ANS Forth for
>cmForth, and because it didn't receive enough review, you figured out that
>it is the only way to implement these words in ANS Forth. We did that
>review with Forth-2012, and it's no longer true, in Forth-2012, all three
>current practice implementations (STATE-smart, dual-xt, SET-COMPILER) are
>legal; and that was the original intention for ANS Forth, too.
>
>If a consensus emerges, we can narrow that down to one option.
As long as we keep S" etc, the right way to implement these words is
dual-xt. I also doubt that you can convince Forth, Inc. and the large
number of traditional systems to switch to a different way.
Therefore I think the way to find consensus is to get rid of S" etc.
Then we can get rid of dual-xt, STATE-smart words, and the
non-use2-compatible xts of VFX.
- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-05-03 21:07 +0100 |
| Message-ID | <mi5v3q$3u0$1@dont-email.me> |
| In reply to | #38586 |
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. But ignoring that, if whatever uses the single xt chooses the correct implementation pointer do the problems associated with dual xts go away? If not what problems remain? -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-03 23:25 +0100 |
| Message-ID | <mi6762$5eh$1@dont-email.me> |
| In reply to | #38799 |
on 03/05/2015 21:07:20, Gerry Jackson wrote:
> 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.
My solution is a cell before the standard interpretation XT that contains
the offset back to the header that contains (amongst other things) a
compilation token that points to the compilation XT. The (slight)
inefficency is in compilation, not interpretation.
: >ct ( xt -- ct ) dup cell- @ + ; \ given an xt, get the ct
begin-structure head% ( header)
..
lfield: head.ct \ compile token action: COMPILE, or execute if IMMEDIATE
lfield: head.xtptr \ ptr to the xt
..
The head.ct would be the target of VFX's SET-COMPILER. The action while
interpreting is <xt> EXECUTE and when compiling is <xt> >CT 2@ EXECUTE.
> But ignoring that, if whatever uses the single xt chooses the correct
> implementation pointer do the problems associated with dual xts go
> away? If not what problems remain?
>
None that I've found so far.
[toc] | [prev] | [next] | [standalone]
| From | gwj.nexus@gmail.com |
|---|---|
| Date | 2015-05-05 10:53 -0700 |
| Message-ID | <18e7c2dd-17ad-4c72-8224-d2668e3cc02c@googlegroups.com> |
| In reply to | #38802 |
So if I understand you, each word has an additional cell to get you to a compilation xt. The scheme I outlined doesn't as all colon definitions, for example, share the data structure that gets to the interpretation and compilation code Not that an extra cell per word is important given the amount of memory available in modern systems. OT: I've had to use Google Groups to reply, and it's awful.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-05 19:10 +0100 |
| Message-ID | <mib0vs$7gr$1@dont-email.me> |
| In reply to | #38845 |
on 05/05/2015 18:54:00, wrote: > So if I understand you, each word has an additional cell to get you to > a co mpilation xt. The scheme I outlined doesn't as all colon > definitions, for e xample, share the data structure that gets to the > interpretation and compil ation code Not that an extra cell per word > is important given the amount of memory available in modern systems. > > OT: I've had to use Google Groups to reply, and it's awful. > Don't snip as much either; I can't work out of you're replying to me or someone else since I use an unthreaded reader.
[toc] | [prev] | [next] | [standalone]
| From | Gerry <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-05-06 21:41 +0100 |
| Message-ID | <midu6t$kme$1@dont-email.me> |
| In reply to | #38846 |
On 05/05/2015 19:10, Alex McDonald wrote: > on 05/05/2015 18:54:00, wrote: >> So if I understand you, each word has an additional cell to get you to >> a co mpilation xt. The scheme I outlined doesn't as all colon >> definitions, for e xample, share the data structure that gets to the >> interpretation and compil ation code Not that an extra cell per word >> is important given the amount of memory available in mode'm rn systems. >> >> OT: I've had to use Google Groups to reply, and it's awful. >> > > Don't snip as much either; I can't work out of you're replying to me or > someone else since I use an unthreaded reader. > Sorry about that, I used Google groups on an Android tablet and it snipped everything, I didn't see an option to include the text I was replying to. I've borrowed a laptop with Thunderbird for this response. I was responding to this bit of your message: <quote sender="Alex McD">My solution is a cell before the standard interpretation XT that contains the offset back to the header that contains (amongst other things) a compilation token that points to the compilation XT. The (slight) inefficency is in compilation, not interpretation. : >ct ( xt -- ct ) dup cell- @ + ; \ given an xt, get the ct begin-structure head% ( header) .. lfield: head.ct \ compile token action: COMPILE, or execute if IMMEDIATE lfield: head.xtptr \ ptr to the xt .. The head.ct would be the target of VFX's SET-COMPILER. The action while interpreting is <xt> EXECUTE and when compiling is <xt> >CT 2@ EXECUTE.</quote> Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-07 11:05 +0100 |
| Message-ID | <mifdbg$5v8$1@dont-email.me> |
| In reply to | #38872 |
on 06/05/2015 21:41:02, Gerry wrote: > On 05/05/2015 19:10, Alex McDonald wrote: >> on 05/05/2015 18:54:00, wrote: >>> So if I understand you, each word has an additional cell to get you to >>> a co mpilation xt. The scheme I outlined doesn't as all colon >>> definitions, for e xample, share the data structure that gets to the >>> interpretation and compil ation code Not that an extra cell per word >>> is important given the amount of memory available in mode'm rn systems. >>> >>> OT: I've had to use Google Groups to reply, and it's awful. >>> >> >> Don't snip as much either; I can't work out of you're replying to me or >> someone else since I use an unthreaded reader. >> > > Sorry about that, I used Google groups on an Android tablet and it > snipped everything, I didn't see an option to include the text I was > replying to. I've borrowed a laptop with Thunderbird for this > response. > > I was responding to this bit of your message: > > <quote sender="Alex McD">My solution is a cell before the standard > interpretation XT that contains > the offset back to the header that contains (amongst other things) a > compilation token that points to the compilation XT. The (slight) > inefficency is in compilation, not interpretation. > >: >ct ( xt -- ct ) dup cell- @ + ; \ given an xt, get the ct > > begin-structure head% ( header) > .. > lfield: head.ct \ compile token action: COMPILE, or execute if > IMMEDIATE lfield: head.xtptr \ ptr to the xt > .. > > The head.ct would be the target of VFX's SET-COMPILER. The action > while interpreting is <xt> EXECUTE and when compiling is <xt> >CT 2@ > EXECUTE.</quote> > > Gerry > > > Yes, there's an extra back pointer in front of the XT (actually, it's an offset from the XT to the parent header; it doesn't require relocation if & when the code is moved). Gforth allows you to find the NT (name token) from the XT, but the doc claims it's not guaranteed to work. I suspect it uses a very similar scheme to my original design, a brute force search of the dictionaries to find a header with a matching XT pointer. This was all very messy when trying to find the CT (compilation token). So I added a back offset which at 4 bytes is reasonably small. Even though it's on the code area, it doesn't impact the run time performance at all as the data is only read and only at compile time. As it's an offset, even if I move it to 64 bit Forth (real soon now ;), its 4 byte size and ability to address 2GB of code & headers is more than adequate. Of course, the CT could have been stored as 8 bytes in front of the XT and taken out of the header. The entire header could have got the same treatment. With Intel chips, they don't take kindly to having data (especially data that's modified) in the code area, hence I split them out.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-08 11:35 +0000 |
| Message-ID | <2015May8.133518@mips.complang.tuwien.ac.at> |
| In reply to | #38883 |
"Alex McDonald" <blog@rivadpm.com> writes:
>Yes, there's an extra back pointer in front of the XT (actually, it's an
>offset from the XT to the parent header; it doesn't require relocation if
>& when the code is moved). Gforth allows you to find the NT (name token)
>from the XT, but the doc claims it's not guaranteed to work. I suspect it
>uses a very similar scheme to my original design, a brute force search of
>the dictionaries to find a header with a matching XT pointer.
No, Gforth up to 0.7.x just tries potential NTs (i.e., addresses
preceeding the code field address), and checks whether that looks like
a name field for the xt. Two failure modes: 1) If the xt has no name;
2) If the heuristic match thinks it sees a name field, but that just
happens to be a bit pattern that fits.
The development version has a different header structure that avoids
failure mode 2 (and, I think, also 1).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 14:09 +0000 |
| Message-ID | <2015May6.160922@mips.complang.tuwien.ac.at> |
| In reply to | #38845 |
gwj.nexus@gmail.com writes:
>So if I understand you, each word has an additional cell to get you to a co=
>mpilation xt.
I don't know whio you are replying to, but anyway: Conceptually yes,
if you want separate compilation semantics, you need an extra compsem
field; if you want an optimizing "COMPILE,", you need an extra
compile, field.
In the implementation, you can optimize that, of course. E.g., have
two flags, one representing the default compsem (then you do not need
the compsem field), one representing the default compile, (then you
don't need the compile, field). We also have discussed other
approaches to reducing the required space. I am not sure that such
optimizations are worth the extra code complexity, though.
- 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-04 03:08 +0200 |
| Message-ID | <mi6gp9$utq$1@dont-email.me> |
| In reply to | #38799 |
Gerry Jackson wrote: > 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. > But ignoring that, if whatever uses the single xt chooses the correct > implementation pointer do the problems associated with dual xts go away? > If not what problems remain? What remains is Anton's difference between SET-COMPILER and SET-COMPSEM. I'm opposed to it, because it makes explaining the language considerably more difficult to people. If it's difficult to explain, it is wrong. IMHO, Anton exposes an "I can only think complicated" trait here (many people can only think complicated and can't take the shortcuts, because that requires out-of-the-box thinking). Forth, as Anton wants it, is that complicated: compilation semantics is different from what COMPILE, does. That's due to his "use 2" corner cases (normal "use 2" is not a problem). My OOTB thninking is: When we have two closely related concepts, isn't it better to heat up the Forth standard a bit and allow it to change so that the two closely related concepts can be made one? Standards usually have to deal with different ways to implement this. That results in complexity by itself, since the standard has to abstract from the different ways. So we have a name token and an execution token. In current Gforth git head, xt and nt are the same thing. Mostly, because there's still the capability for dual-xt, which makes interpret/compile: xts an exception (SET-COMPSEM xt's a semi-exception - name, xt and interpretation semantics are tied together). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-04 09:23 +0100 |
| Message-ID | <mi7a7u$v6q$1@dont-email.me> |
| In reply to | #38806 |
on 04/05/2015 02:08:52, Bernd Paysan wrote: > Gerry Jackson wrote: > >> 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. >> But ignoring that, if whatever uses the single xt chooses the correct >> implementation pointer do the problems associated with dual xts go away? >> If not what problems remain? > > What remains is Anton's difference between SET-COMPILER and > SET-COMPSEM. I'm opposed to it, because it makes explaining the > language considerably more difficult to people. If it's difficult to > explain, it is wrong. > > IMHO, Anton exposes an "I can only think complicated" trait here (many > people can only think complicated and can't take the shortcuts, > because that requires out-of-the-box thinking). Forth, as Anton wants > it, is that complicated: compilation semantics is different from what > COMPILE, does. That's due to his "use 2" corner cases (normal "use 2" > is not a problem). Can you give an example of a use 2 case that is normal vs (for want of a better word) an abnormal one? > > My OOTB thninking is: When we have two closely related concepts, isn't > it better to heat up the Forth standard a bit and allow it to change > so that the two closely related concepts can be made one? > > Standards usually have to deal with different ways to implement this. > That results in complexity by itself, since the standard has to > abstract from the different ways. So we have a name token and an > execution token. In current Gforth git head, xt and nt are the same > thing. Mostly, because there's still the capability for dual-xt, which > makes interpret/compile: xts an exception (SET-COMPSEM xt's a > semi-exception - name, xt and interpretation semantics are tied > together). >
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-04 20:32 +0200 |
| Message-ID | <mi8duc$8me$1@dont-email.me> |
| In reply to | #38807 |
Alex McDonald wrote: >> IMHO, Anton exposes an "I can only think complicated" trait here (many >> people can only think complicated and can't take the shortcuts, >> because that requires out-of-the-box thinking). Forth, as Anton wants >> it, is that complicated: compilation semantics is different from what >> COMPILE, does. That's due to his "use 2" corner cases (normal "use 2" >> is not a problem). > > Can you give an example of a use 2 case that is normal vs (for want of a > better word) an abnormal one? Assume, you want to redefine deferred words, you write : defers ( "name" -- ) ' defer@ compile, ; immediate That's use 2, the token obtained by defer@ is usually executed by defers. Standard case is something like Defer hello : colloquial ." Hi" ; ' colloquial is hello Abnormal case (using comp: as syntactic sugar for SET-COMPILER): : weird ." Hi" ; comp: drop ]] "Bye" type [[ ; ' weird is hello hello Hi ok : weird2 defers hello ." all" ; ' weird2 is hello hello Bye all ok -- 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-06 13:26 +0000 |
| Message-ID | <2015May6.152633@mips.complang.tuwien.ac.at> |
| In reply to | #38806 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Gerry Jackson wrote:
>
>> 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.
>> But ignoring that, if whatever uses the single xt chooses the correct
>> implementation pointer do the problems associated with dual xts go away?
>> If not what problems remain?
>
>What remains is Anton's difference between SET-COMPILER and SET-COMPSEM.
>I'm opposed to it, because it makes explaining the language considerably
>more difficult to people. If it's difficult to explain, it is wrong.
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:
"Here we want to delay execution by one level; the general way to do
it is to use POSTPONE LITERAL POSTPONE EXECUTE, but that is slow. So
if you are sure that you always ever get only xts of words with
default compilation semantics, you can use COMPILE,."
And of course the programmer would then use COMPILE, and have to
document the restriction on the xts, 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.
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.
And even if nobody ever falls into this trap (like nobody ever fell
into the STATE-smart trap), 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.
>IMHO, Anton exposes an "I can only think complicated" trait here (many
>people can only think complicated and can't take the shortcuts, because that
>requires out-of-the-box thinking). Forth, as Anton wants it, is that
>complicated: compilation semantics is different from what COMPILE, does.
>That's due to his "use 2" corner cases (normal "use 2" is not a problem).
No need for you to go into Hugh Aguilar mode. 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; 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.
>My OOTB thninking is: When we have two closely related concepts, isn't it
>better to heat up the Forth standard a bit and allow it to change so that
>the two closely related concepts can be made one?
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. 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. 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.
- 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-06 20:00 +0200 |
| Message-ID | <midkpt$dlj$1@dont-email.me> |
| In reply to | #38861 |
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. You don't have to explain that it is different in the text interpreter vs. the tokenized form, you don't have to explain that FIND may return two different xts depending on STATE, etc. 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. > 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. > 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. 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. In other words: You are totally locked into a world-view which very few people share with you, but you can't see that your lock-in. You think it's "natural" to think that way. > 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. Having this sort of sublte difference is looking for troubles. This part of the Forth system is complicated enough that people have problems getting into, especially, because we are talking about things that don't happen in other programming languages. 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. > 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. This thing you fell over was in bigForth for years, IIRC it was taken over from volksForth. Your problem was that you had a wrong mental model of how Forth compilation works, caused by the ANS Forth standard. They talk about semantics. It actually was a state of the system (back then, STATE-smart was common). This discrepancy between actual implementation and the way the TC wrote about it made you fall into that trap. Most people didn't read the ANS Forth document to understand Forth, but text books and source code (with STATE-smart words). Therefore, they didn't have that mental model. The concept of semantics is actually a good idea, but it is something we should revisit, because it never did match with reality. Apart from Gforth, which was changed to match with the standard. That's the wrong way round. > 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. I think you are the most problematic person to be taught the new semantics, because you have way too much a-priori knowledge which needs to be untaught. You have fully bought the ANS Forth semantics stuff, the rest of the Forth world didn't. > No need for you to go into Hugh Aguilar mode. 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. There was an RFI about STATE-smart words which the TC answered, it was about using STATE-smart words for optimization (example: + as state-smart word). The TC response was that this was the wrong approach. So there is a consensus about not using STATE- smart for optimizations. Instead, there's a much broader consensus for using SET-COMPILER for optimizations (even you agree). 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. 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. Actually, after your "can we tick EXIT" question, that *is* standard, but it is a stupid way of being standard: You can't do that, because you can't meaningfully tick >R. These problems are all holes of the needlessly complicated model of the current standard. > 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. >>My OOTB thninking is: When we have two closely related concepts, isn't it >>better to heat up the Forth standard a bit and allow it to change so that >>the two closely related concepts can be made one? > > 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". > 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. Yes, and why? Because there's a subtle difference, which is unnecessary and complicates the whole language. You are creating an artificial difference between things that IMHO should *not* be different. They are different, because the TC did make a relatively good job with the semantics, but not a perfect job. The difference is just a mistake! > 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,. 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. That's a very straight-forward equivalence, no stublte differences, and it's easy to memorize what you get in the corner cases (special compilation semantics is a corner case). Those out-of-the-box shortcuts are necessary to simplify concepts; if you have a pure legacy view, you can't take these shortcuts, and you are making the world more complex than it needs to be. The box is not the boundary of the universe. It's just cardboard. -- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-06 13:24 -0700 |
| Message-ID | <f10e5c36-97e1-46ee-8413-748f0e6e0d73@googlegroups.com> |
| In reply to | #38866 |
On Wednesday, May 6, 2015 at 11:00:30 AM UTC-7, Bernd Paysan wrote:
> You are totally locked into a world-view which very few
> people share with you, but you can't see that your lock-in. You think it's
> "natural" to think that way.
So long as Anton Ertl shares his world-view with his bosses, then he keeps his job --- this world-vies is that it is impossible to write an outer-interpreter in standard Forth and hence impossible to write a cross-compiler. It doesn't have to be "natural" to the Forth world (it never existed prior to ANS-Forth) --- so long as the boss says that it is natural, then you say that only a fool would expect to write a cross-compiler in ANS-Forth, and if the boss says that the sky is orange, then you say that only madmen see it as being blue.
> 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. And at least for return-stack words, that
> optimization is crucial, if you don't optimize, they don't work.
I don't know what "cmForth-like dual-xt Forths" mean, and I don't care. In MFX most words (DUP etc.) existed in both HOST mode and TARG mode. The TARG mode version worked on the target processor and the HOST mode version was immediate and worked on the host processor (it compiled the TARG mode word). These words were in different word-lists and had different xt values. Because it was possible to examine an xt and determine which word-list it was in, there was never any confusion about which word was which. There were some words (hand-written immediate words such as IF) that existed only in HOST mode and didn't have a TARG mode version.
Now that I have figured out how to disambiguify ANS-Forth, I can do this in ANS-Forth too.
> I.e. in
> cmForth, you can't do
>
> ['] >r compile,
>
> and get the expected result. Actually, after your "can we tick EXIT"
> question, that *is* standard, but it is a stupid way of being standard: You
> can't do that, because you can't meaningfully tick >R.
Disambiguify >R like this:
: >r state @ 0= abort" *** no interpretation semantics for: >R ***"
postpone >r ; immediate
Now you can tick >R meaningfully. If you execute it in compilation mode, it will work as expected. If you execute it in interpretation mode, then you get an abort with this message: " *** no interpretation semantics for: >R ***" This is expected too --- and the error message explains exactly what the mistake was, so your bug can be easily fixed.
Tick has always been problematic to use, because it doesn't tell you if your word is immediate or non-immediate. This has always been true, and continues to be true with my disambiguifiers. This is why FIND is used when writing outer-interpreters rather than tick --- for the most part, tick is just a convenience for cases in which you know a-priori if the word is non-immediate or immediate, but you can't rely on a-priori knowledge when you are working with a user-entered string rather than a string that you typed in yourself as part of your own source-code.
All of this stuff seems easy and obvious to me. The fact that you two are pondering it and unable to understand it, implies one of two things:
1.) You are both dumb as beagles.
2.) You are playing dumb in an effort to hide your agenda, which is to make cross-compilation impossible in a standard program, so cross-compilers can only be written by compiler-vendors using carnal knowledge.
In case #2, I have already defeated you with my disambiguifiers.
In case #1, you should just resign from the Forth-200x committee on the basis that you aren't qualified.
> > 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.
In MFX, there were actually a total of three versions of + and ! and most other words:
SYSTEM --- These ran on the host computer and accessed host memory. This is what executed in interpretation mode, and compilation mode of SYSTEM or HOST words. These could be either immediate or non-immediate. These were actually the FORTH-WORDLIST (FORTH vocabulary in Forth-83) words built into the system.
HOST --- These ran on the host computer and accessed target memory (the image that would later get uploaded). These were immediate, so they got executed in compilation mode of TARG words, but not of HOST words in which case they weren't found (wrong word-list).
TARG --- These ran on the target computer and accessed target memory. These were non-immediate (there was no outer-interpreter on the target computer).
For the most part, nobody ever wrote SYSTEM words (this is why I sometimes say for convenience that there are two versions: HOST and TARG) --- programmers only wrote HOST or TARG words (actually, a novice could get by only writing TARG words --- HOST words were only for meta-compiling, which is more advanced than many users want to get into).
I had these words for ticking in interpretation mode: S' H' and T'
I had these words for ticking in compilation mode: [S'] [H'] and [T']
The programmer just used whichever ticker was appropriate to what he wanted to obtain (use S' to get a SYSTEM word, use H' to get a HOST word, use T' to get a TARG word). I didn't have ' and ['] because these would have been ambiguous (I don't tolerate ambiguity). This system is very simple --- there is no confusion for the programmer --- anybody can learn to use such a system with minimal instruction (my coworker figured it out from my one page documentation and never had to ask any questions).
I figured all of this out in 1994 when I wrote MFX --- it is exasperating for me to see the Forth-200x committee baffled by the concept of Forth compilation in the year 2015 --- I'm leaning toward the "dumb as beagles" explanation, as this stuff is really quite easy --- if you just engage your brain, it should be obvious.
[toc] | [prev] | [next] | [standalone]
Page 22 of 26 — ← Prev page 1 … 20 21 [22] 23 24 … 26 Next page →
Back to top | Article view | comp.lang.forth
csiph-web