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-06-15 23:35 +0000 |
| Articles | 20 on this page of 325 — 39 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 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 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-06-23 10:30 +0000
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
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-13 00:11 +0200 |
| Message-ID | <mittol$47s$1@dont-email.me> |
| In reply to | #39036 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >> >>>>No, Anton, you don't. You just say that COMPILE, performs the >>>>compilation semantics. >>> >>> But it doesn't, not even on VFX: >>> >>> : foo ." foo" ; immediate ok >>> : bar [ ' foo compile, ] ; ok >>> : bar2 foo ; foo ok >> >>Straw man, that's using a legacy feature which is there because the >>standard says you must have it - this way. > > Are you sure you know what a straw man argument is? Sure. The german word is "Trugschluss". We have a legacy approach at compiler macros: that's IMMEDIATE, plus STATE for special compilation semantics. > Anyway, it's standard and every system implements it this way. So > it's not just common practice, but universal practice. You propose > changing that. You would need very good arguments for that, and you > failed to do that yet. Most of the problems with IMMEDIATE are already in RFI 7. That's not limited to STATE-smart words. > No I don't have to explain that, I just explain that an execution > token stands for one semantics; EXECUTE executes it, and COMPILE, > appends it to the current definition. And I consider that simpler > than saying that an xt stands for a lot of different things, that > EXECUTE does one thing, and COMPILE, may do something completely > unrelated. Anton, the simpler thing is that an xt is a number that represents a word. If you need three different tokens to represent a word (nt for the name, xt for execution and ct for compilation), you have a 1:3 relation. 3 is more than 1, having three different tokens, several converters back and forth is not simple. If you define a word that does two completely unrelated things depending on state, that's a bad idea. But if somebody does this bad thing, it's most consequential that it does this bad thing when encountered as name in the input stream as well as when encountered as xt. : weird ." foo" ; comp: drop ." bar" ; is a weird word, which prints "foo" in interpretation mode, and "bar" in compilation mode. It makes no sense to be that weird, but it is consistent behavior if ' weird execute prints that "foo" and ' weird compile, prints that "bar". COMPILE, does not something "completely unrelated", here it just compiles WEIRD. The only surprising element is the implementation of WEIRD, but it is consistent between textual representation and token representation. > What's wrong with > > defer name>x \ not the Gforth word of the same name > : ] ['] name>compile is name>x ; > : [ [: name>interpret dup 0= -14 and throw ;] is name>x ; > > \ and here the text interpreter: > parse-name find-name dup 0= -13 and throw name>x execute What's wrong with that? name>x has a variable stack effect. As long as you just EXECUTE that, it works fine. If you want to do something else (e.g. just resolve some names and let them be compiled or executed later), it's not going to work. Example for such tokenizing and later resolving: a dot parser for an OOP system that can parse something like "object.subobject.method". The proposed interpreter would look like this: defer do-xt ( xt -- ) : ] ['] compile, is do-xt ; : [ ['] execute is do-xt ; parse-name find-xt dup 0= -13 and throw do-xt do-xt has a simple, constant stack effect. There's only one kind of token, which can be used as universal token, not just as execution token (use xt>string instead of >name name>string to get at the name). Words wouldn't have flags anymore. For legacy code, you might have : immediate ['] execute set-compiler ; > IMMEDIATE fits nicely in the system above, and STATE could be > implemented to behave as it always has. You can always make tradeoffs between simplicity and compatibility. > That may be the case, but you have not documented that one must only > pass words with default compilation semantics to DEFINES in mini-oof. "By example" is good enough for the amount of documentation I made. > No, it holds for all words in fig-Forth, including STATE-smart words. > STATE-smart words have other problems, but the equivalence between > EXECUTE and COMPILE, holds for them. fig-Forth's " wasn't state-smart. It was compile-only. You got the compilation semantics if you did ' " >CFA ,. The "execution semantics" of " was to report an error, or silently just compile the string (IIRC, the latter). You keep on and on with ignoring that your equivalence doesn't work with compile-only immediate words. I don't know what to do. Once again: ' <compile-only+immediate> COMPILE, appends the compilation semantics, i.e. is equivalent to [COMPILE] and POSTPONE of that name. It's *not* equivalent to encountering that word in the text interpreter in interpretation state. I think your problem is that you stop half-way in the argument. The standard mandates: Equivalence 1: foo === ' foo execute \ in interpretation mode Equivalence 2: ' foo compile, === ' foo postpone literal postpone execute Equivalence 1 resulted in RFI 8, which says that ' is undefined if ' FOO EXECUTE doesn't equal to FOO (compile-only words). That means that equivalence 2 is meaningless for these cases, too, because ' FOO for a compile-only FOO is meaningless. We already agreed on that on EuroForth. And it's not just meaningless, it does not what people would expect it to do (in the current system). For a number of compile-only words, people can't know whether they are immediate or not (the standard doesn't tell). But here, if you want to do something like ' EXIT COMPILE,, it matters. In my proposed system, it doesn't matter. If EXIT is an alias to ;S, and has default compilation semantics, ['] EXIT COMPILE, will produce exactly the same effect as the Gforth EXIT, which cleans up the local stack, too. Gforth "avoids" this problem by not allowing to tick EXIT. I.e. you just can't do it. But it's pretty obvious what that ['] EXIT COMPILE, should do, and you can directly infer it from the standard. EXIT by specification has only execution semantics without interpretation semantics. >>It's there by example: All xts passed to defines in mini-oof are :noname >>xts. > > That's not documentation. You pass only three xts to DEFINES, but I > don't think that you want users to think that they may pass only one > of these three xts. Another straw man. Documentation by example means that you can savely follow the pattern laid out in the example. There are three :noname <some stuff> ; <class> defines <method> examples. People can and do recognize such patterns and are able to apply them. It's one of the things humans are pretty good at. >>: :: ( class "name" -- ) ' >body @ + @ compile, ;" > > So you expect that the user understands subtle implementation details > of mini-OOF in order to use it (such as the flow of the xt from > DEFINES to COMPILE,), but you don't tell that to the user. Yes, I do indeed assume that the target audience is capable of reading a few lines of Forth code. >>When you choose option 1 (named words, no :: needed), you'll get into the >>troubles you describe with SET-COMPSEM, too. > > No, if the user writes a named word, there is no xt passed to the > COMPILE, in mini-oof. If the user uses named words like this : base:method <some words> ; ' base:method base defines method and later : derived:method <some more words> base:method ; ' derived:method derived defines method base:method goes through the text interpreter, which COMPILE,s it. If there's a SET-COMPILER on base:method, this part will get executed. It's 100% the same situation. > Sure, the user will get the compilation > semantics when he writes a named word in a definition, but that's very > familiar territory to users (they use the text interpreter a lot, much > more than ', EXECUTE, and COMPILE,). The advantage of my approach is that there's a very straight-forward correspondence from the familiar territory to EXECUTE and COMPILE,. Much more straight-forward than the text interpreter is now. So when the people wouldn't be surprised of what a base:method with a set- compiler thingy would do to derived:method, they wouldn't be surprised that early binding (with COMPILE,) does the same. > As long as we only have those few words, rarely a problem (and that > problem is covered in the standard by disallowing ticking these words). We have more words where the standard disallows ticking, because of closely related problems. While it is pretty easy to explain why TO and S" are problematic, it is much more difficult to explain why EXIT and such are problematic. They shouldn't. Since you have argued that my DUP is just instrumentation and not changing compilation semantics: What's the case with Gforth's EXIT? It cleans up the locals stack. Is that changing the compilaton semantics or is it still doing the default compilation semantics? > But you suggest using SET-COMPILER instead of SET-COMPSEM not just for > these few words, but for defining words that might be used to define > many other words. I would not bet that nobody ever ticks the result > of such a defining word and never passes it to COMPILE,add. I'd like to have an obvious and straight-forward correspondence between interpretation, compilation, execution tokens and EXECUTE plus COMPILE,. That way it is pretty easy to describe what will happen in that case, and when it's obvious and easy, people understand the consequences. They might still want to COMPILE, the word, but they know what it does. > It certainly works for ordinary immediate words in all current Forth > systems. It works for user-defined words like that, but as you said, users shouldn't define such words. Leaves the system-defined words of that class. And there, it doesn't work. >>We can continue as we do now, and say this sort of stuff is simply not >>supposed to work portably. Or we say it's supposed to work in the next >>standard, and we then have to chose how. STATE-smart, SET-COMPILER or >>dual- xt are already implemented, and the three behave different. > > I think the way to go for the standard is to leave them as-is and turn > them into legacy (and eventually obsolete) with recognizers. For a > system, the right thing to do is still deciding at parse/FIND time, > not later; the other solutions are good enough, though, as long as > their use is kept to a minimum. That's where I disagree. Parse/FIND should not decide, it should just do the same thing regardless of state. What happens with the parsed/found stuff can depend on the state, but not earlier. The recognizer proposal is pretty clear about that: The recognizer is doing all the parsing and searching, but *not* doing any state-dependent stuff. The reason why a recognizer is much better than STATE-smart is actually that: It's stateless, always doing the same thing, predictable. >>That doesn't remove other dual-xt problems. > > What other problems? The ones you keep ignoring. Things like (not complete): * Words like FIND or recognizers shall not be STATE-dependent * Having three different tokenized representations of a word is overly complex * MY' example earlier on > I don't know what iForth actually uses. I would base optimization on > "COMPILE,", but basing it on compilation semantics is also possible > and does not lead to any problems except that you have to teach > [COMPILE] what is default compilation semantics and what is not; Or just don't support it any longer. It's obsolescent now. > No. My argument is that in the current standard the equivalence > between EXECUTE and COMPILE, holds for all xts you can get in a > standard program. If it doesn't, the system is non-standard. That must exclude xts you can get with FIND. The MY' using FIND can easily get such xts, and unlike ', there's no ambiguous condition on FIND. It will return an xt for every defined word (or two different, depending on state). > And it does hold. Nope. For all immediate compile-only xts found by FIND, which are specified in the standard only with execution semantics (like EXIT in Gforth), it doesn't. Current git-head Gforth has a set-compiler non-immediate EXIT, though, making it possible to COMPILE, the xt returned by FIND. >>If we want to make the behavior of use 2 portable across popular >>implementations, two out of three have to give in. > > Nobody has to give in. It works already. Including VFX? So then the SET-COMPILER approach is ok then? -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-04 16:58 +0000 |
| Message-ID | <2015May4.185829@mips.complang.tuwien.ac.at> |
| In reply to | #38799 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 25/04/2015 00:21, Bernd Paysan wrote:
>> 3. dual-xt has been critisized by Stephen Pelc, because it breaks the
>> conceptual unit of name and xt (where the xt is just a token for the name)
>
>I've not really been following the discussion about whether dual xt's
>are good or bad. But if you have a system where the xt is the address of
>a pointer that points to a small structure containing:
>1. a pointer to code implementing interpretation semantics
>2. a pointer to code implementing compilation semantics
>
>This is clearly less efficient as it has another level of indirection.
Well, about 0.5% of the executed primitives are EXECUTE in my
benchmarks <http://www.complang.tuwien.ac.at/forth/peep/sorted>, so
having one @ more in that case is not a big cost. And you can avoid
it with the following arrangement:
more header fields
compsem field
compile, field
native code
Disadvantage: code close to data; even if the data is just read, it
will slow down execution on old CPUs such as Pentium and AMD K6;
hopefully not in any newer ones. However, it is probably not frequent
to alternatingly run a word and, e.g., COMPILE, or NAME>COMP it, so
even on these CPUs, it should not be a big issue. The lower cache
utilization of the I and D caches are another disadvantage (which may
be more relevant than the cost of the additional @ for separated
headers).
>But ignoring that, if whatever uses the single xt chooses the correct
>implementation pointer do the problems associated with dual xts go away?
What problems?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | gwj.nexus@gmail.com |
|---|---|
| Date | 2015-05-05 11:24 -0700 |
| Message-ID | <8cf16d90-8de3-488a-88f1-52a7c2b61190@googlegroups.com> |
| In reply to | #38816 |
I should have made my question a bit more precise. I meant the problems with the xt that FIND returns, why S" and TO can't be ticked or postponed - generally everything that dual xts, SET-COMPILER and COMPSEM (or SET-COMPSEM) solve in their different ways. With the scheme I outlined there is only 1 xt so FIND should not be a problem. Bernd states that what remains is the difference between SET-COMPILER and SET-COMPSEM. Looking back through this discussion and a previous one, Stephen Pelc has given a description of SET-COMPILER but I can't find a description of SET-COMPSEM or COMPSEM, they just seem to have entered into the discussion without a clear idea of what they do or the problem they solve. Perhaps you can clarify this.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 13:13 +0000 |
| Message-ID | <2015May6.151313@mips.complang.tuwien.ac.at> |
| In reply to | #38847 |
gwj.nexus@gmail.com writes:
>Bernd states that what remains is the difference between SET-COMPILER and S=
>ET-COMPSEM. Looking back through this discussion and a previous one, Stephe=
>n Pelc has given a description of SET-COMPILER but I can't find a descripti=
>on of SET-COMPSEM or COMPSEM, they just seem to have entered into the discu=
>ssion without a clear idea of what they do or the problem they solve.
SET-COMPSEM changes the compilation semantics of a word, i.e., what
the text interpreter does when it encounters the word in compile
state, what NAME>COMPILE produces, and what FIND produces in compile
state.
The difference from SET-COMPILER is that the latter influences uses of
COMPILE, outside text interpreters, where COMPILE, is meant to be
equivalent to
: compile, postpone literal postpone execute ;
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-24 13:11 -0700 |
| Message-ID | <16284915-3f02-485e-971a-589e12664690@googlegroups.com> |
| In reply to | #38504 |
On Wednesday, April 22, 2015 at 8:42:17 AM UTC-7, Stephen Pelc wrote: > The permission to return different xts in interpretation and > compilation states was a concession to cmForth. Exploiting > this concession is itself a mistake im my opinion because it > reopens the box that xts were designed to keep shut. Earlier in this thread I said: On Wednesday, April 1, 2015 at 12:33:51 PM UTC-7, hughag...@gmail.com wrote: > On Wednesday, April 1, 2015 at 4:26:52 AM UTC-7, Stephen Pelc wrote: > > I have been saying for a couple of years now that the ANS > > standard's definition of compilation and interpretation is > > incomprehensible for mere mortals such as myself. Every time > > I reread the standard on this topic, the more I believe that > > the standard's description of compilation and interpretation > > needs a complete rewrite. > > > > In essence, Forth is a language of simplicity. Complexity such > > as an optimising compiler is hidden. However, we now have a > > standard in which the classic Forth interpreter loop is > > broken according to some. We need to fix this by going back > > to basics rather than putting bandages on bad prose. > > I've been saying since 2009, which is more than a couple of years, that the solution is to define the language as a cross-compiler. In MFX I had HOST and TARG modes, so it was obvious which words were compile-time or run-time. Everything that runs at compile-time (either in the REPL or an immediate word used in a colon-word definition) had to have been defined in HOST mode. Everything that runs at run-time (on the MiniForth processor in the case of MFX) is defined in TARG mode. Also, every TARG mode word is defined twice --- we have the run-time version that executes on the target machine, and we have a compile-time version that is automatically generated as if it were hand-written in HOST mode and which compiles the TARG-mode version of itself --- these two words are in separate vocabularies and have distinct xt values, so there is no confusion between them. > > A cross-compiler is somewhat complicated to write, but using the cross-compiler is actually simpler for the user (presumably a "mere mortal") than using ANS-Forth is, because there is no confusion between "interpretation semantics" and "compilation semantics" as there is in ANS-Forth. You are using the term "semantics" that is defined as "the meaning of words" --- so it would make sense if two kinds of semantics (interpretation and compilation) are in distinct vocabularies, because they have different meanings --- but in ANS-Forth you have both kinds of semantics jumbled together in the same vocabulary (the FORTH-WORDLIST vocabulary), which is why it is confusing and will continue to be confusing indefinitely, and won't be cleared up by rewriting the ANS-Forth document as you suggest. > > The HOST mode words are written in a Forth running on the desktop-computer (I used UR/Forth for MFX, but am using VFX now). This host Forth still has the same problem as before, with compile-time words and run-time words jumbled together in the same vocabulary, so all that I've succeeded in doing is pushing the problem uphill, but the problem is still there. Pushing the problem uphill is actually quite helpful though, because it gets the problem out of the way for the common user. Programming is done at three levels, and the problem has been pushed all the way up to level-3, so most programmers never bump into the problem. These are the levels: > 1.) novice: Writes only in TARG mode. These guys typically came from a C programming background and don't know what "compile-time code" is --- this is common --- everybody starts here, and they can make a career out of writing application programs without learning any more than this. > 2.) intermediate: Writes in both TARG mode and HOST mode, but only writes HOST mode words that execute at run-time for HOST mode (which is compile-time for TARG words) --- this is rare --- it is only necessary to work at this level when adding any meta-compiling word to the cross-compiler. > 3.) advanced: Writes in both TARG mode and HOST mode, and writes HOST mode words that execute at compile-time for HOST mode (bumping into the aforementioned problem) --- this is extremely rare (I'm the only person who has ever done this) --- it is necessary when retargeting the cross-compiler for a new processor. > There are other problems in the gForth perspective, especially > in that you can't write a full Forth text interpreter in the > classical model. I think that gForth's perspective, which involves making it impossible to write an outer-interpreter (full Forth text interpreter), was done for the purpose of making it impossible to write a cross-compiler. You are the only person to benefit from this, because you make money selling cross-compilers and you don't want people to use gForth to write their own cross-compiler without paying you any money. But you now describe this as being a problem? A problem for who? It is not a problem for you, but it is only a problem for me. Since when are you concerned about helping me make money in competition with you? More likely, is that you paid the gForth developers (Anton Ertl and Bernd Payson) under the table to cripple gForth so that gForth couldn't be used for writing a cross-compiler by people like me. > I know that you and I are not going to agree on this topic, but > when you raise such issues, you should at least acknowledge > that there are differences of opinion on the topic. The Forth > 202x technical committee should start by having a long > discussion about what compilation in Forth actually involves. Differences of opinion? That is why I got kicked off the Forth-200x mailing list --- you didn't seem very interested in hearing about differences of opinion then. Anyway, it is not "impossible" --- I figured out a work-around for the problem, that uncripples both VFX and gForth despite the fact that VFX and gForth respond to the "ambiguous condition" differently from each other (it took me over 5 years to come up with this): : +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate : ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate : ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate : >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate : abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate : begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate : do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate : does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate : else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate : exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate : I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate : leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate : literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate : loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate : r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate : r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate : recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate : repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate : s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate : then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate : unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate : until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate : while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate : [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate : ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate : [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate : 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate : 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate : 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate : ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate : again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate : c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate : case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate : compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate : endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate : endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate : of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate : [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate : 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate : fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate : (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate : locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate : ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate : ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate : cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate : cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate : sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-25 21:05 -0700 |
| Message-ID | <a7370747-a015-4cd2-a68b-e4f5f03663b8@googlegroups.com> |
| In reply to | #38581 |
On Friday, April 24, 2015 at 1:11:06 PM UTC-7, hughag...@gmail.com wrote: > On Wednesday, April 22, 2015 at 8:42:17 AM UTC-7, Stephen Pelc wrote: > > There are other problems in the gForth perspective, especially > > in that you can't write a full Forth text interpreter in the > > classical model. > > I think that gForth's perspective, which involves making it impossible to write an outer-interpreter (full Forth text interpreter), was done for the purpose of making it impossible to write a cross-compiler. You are the only person to benefit from this, because you make money selling cross-compilers and you don't want people to use gForth to write their own cross-compiler without paying you any money. But you now describe this as being a problem? A problem for who? It is not a problem for you, but it is only a problem for me. Since when are you concerned about helping me make money in competition with you? More likely, is that you paid the gForth developers (Anton Ertl and Bernd Payson) under the table to cripple gForth so that gForth couldn't be used for writing a cross-compiler by people like me. I meant to say: "A problem for whom?" I apologize for the bad grammar.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-21 14:06 +0100 |
| Message-ID | <mh5hua$e5m$1@dont-email.me> |
| In reply to | #38433 |
on 21/04/2015 10:10:16, Mark Wills wrote: > > I don't see it as a conspiracy - it's just a bit of a mess. It's just > that some words don't do anything meaningful when not in compilation > state. IF is actually a good example. Executing IF at the command > line would cause some code to be compiled into memory, which is > meaningless, because you can't execute it. Hugh would rather lash out and attack people than address the source of the problem -- which is his behaviour. Only once he's fixed his rage and furstation can he possibly ever move on to work on a solution. For example, he was just plain wrong when he stated he could write an ANS Forth SYNONYM, but (as usual) I haven't seen him propose changes to the spec that would help. Just daft conspiracy theories that make him look like he's having a toddler temper tantrum. To the case in point. Worse than not only possibly compile some code into the code area, such a word might also put the control flow for ORIG on the stack. Or it might not, since to quote the spec; "Interpretation semantics for this word are undefined". That's undesirable to say the least. What is required is to eliminate STATE, find a replacement for FIND, and work on what is meant by interpret and compile and the definition of XT. There have been many threads about this on clf over the years. Sadly for us Hugh has just noticed this, and so CLF has to watch him throw a fit.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-22 20:05 -0700 |
| Message-ID | <ffc07822-7a0a-47e0-8d72-4aa6c5bb903d@googlegroups.com> |
| In reply to | #38433 |
On Tuesday, April 21, 2015 at 2:10:21 AM UTC-7, Mark Wills wrote:
> On Tuesday, 21 April 2015 07:21:06 UTC+1, hughag...@gmail.com wrote:
> > I figured out what is going on here.
> >
> > ANS-Forth has words that either lack an xt, or have an xt that aborts when executed. The purpose of this is to prevent common Forth programmers from writing cross-compilers. The outer interpreter in a Forth system is using a version of FIND that returns valid xt values for ALL words --- it wouldn't be able to work otherwise --- but the version of FIND that is provided to the common programmers has been sabotaged so that it doesn't return a valid xt value for some of the words. The result is that the common Forth programmer is not able to write an outer interpreter of his own. So, who wants to write an outer interpreter? Cross-compiler writers!
> >
> > The ANS-Forth standard was sabotaged to prevent common programmers from writing cross-compilers. This is because Forth Inc. and MPE make most of their money selling cross-compilers. I have really caught the ANS-Forth committee red-handed --- they sabotaged the Forth community on purpose --- they do not deserve any respect ever again from the Forth community!
>
> I don't see it as a conspiracy - it's just a bit of a mess. It's just
> that some words don't do anything meaningful when not in compilation
> state. IF is actually a good example. Executing IF at the command
> line would cause some code to be compiled into memory, which is
> meaningless, because you can't execute it. That's why VFX aborts if
> you attempt to execute IF when state=0. That's entitled behaviour,
> as the interpretation semantics of IF are undefined.
Mark, you totally failed to understand my example code:
: my-if [ ' if ] literal execute ; immediate ok
: ttt ( flag -- ) my-if ." true " else ." false " then ;
Err# -14 ERR: Attempt to interpret a compile only definition.
-> : ttt ( flag -- ) my-if ." true " else ." false " then ;
^
see my-if
MY-IF (is IMMEDIATE)
( 004C7A80 E89B23F4FF ) CALL 00409E20 IF
( 004C7A85 C3 ) NEXT,
( 6 bytes, 2 instructions )
ok
MY-IF is executing inside of a colon-word definition --- this is compilation mode --- it should have worked.
FIND has been sabotaged to provide a bad xt value for certain words; these include IF and everything else listed in the ANS-Forth manual to have "interpretation semantics undefined".
The outer interpreter in VFX uses a different version of FIND that is not sabotaged. This version of FIND provides a valid xt value for all words (including IF etc.). The outer interpreter gives this good xt value to EXECUTE (because it is an immediate) word, and it works correctly.
The FIND provided to the user has been sabotaged to provide xt values for these words (IF etc.) that will abort when given to EXECUTE. In the case of gForth, FIND itself aborts when it is told to look up the xt of these words (I noticed this in 2009 when my code aborted when it tried to tick semi-colon).
This is not "just a bit of a mess" --- this is cripple-ware --- VFX was crippled in such a way as to prevent the programmer from writing his own outer interpreter. Writing an outer interpreter is crucial to writing a cross-compiler. Stephen Pelc provided the VFX users with a crippled FIND that fails for certain words. He did this for the purpose of preventing his users from using VFX for writing a cross-compiler. This is because he makes most of his money selling cross-compilers, and he doesn't want people to use VFX to compete against him.
I defeated this sabotage however:
: if
state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate
: my-if [ ' if ] literal execute ; immediate ok
: ttt ( flag -- ) my-if ." true" else ." false" then ; ok
1 ttt true ok
0 ttt false ok
Now FIND provides a valid xt for IF --- this is the key to using VFX to write an outer interpreter --- this is how Stephen Pelc's cripple-ware can be uncrippled so that VFX can be used for writing a cross-compiler in competition with MPE.
I don't really blame Stephen Pelc for selling cripple-ware. He is in the business of selling cross-compilers, and he doesn't want people to use VFX to write their own cross-compiler in competition with him.
I do blame Anton Ertl for whitewashing this sabotage. And I blame the ANS-Forth committee for saying that a sabotaged FIND is actually standard. This is grossly dishonest. All that pseudo-intellectual blather that Anton Ertl was giving me, to the effect that I shouldn't expect FIND to work for all the words (IF etc.), was whitewash. He is lying. He is protecting Forth Inc. and MPE, by lying to the Forth community. I think this is really the end of Anton Ertl's career. Nobody will ever trust him again. He is just a stooge of Forth Inc. and MPE --- he is lying to the Forth community --- he doesn't deserve any respect at all.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-23 05:57 +0000 |
| Message-ID | <2015Apr23.075727@mips.complang.tuwien.ac.at> |
| In reply to | #38523 |
hughaguilar96@gmail.com writes:
>Mark, you totally failed to understand my example code:
>
>: my-if [ ' if ] literal execute ; immediate ok=20
>: ttt ( flag -- ) my-if ." true " else ." false " then ;=20
>Err# -14 ERR: Attempt to interpret a compile only definition.=20
> -> : ttt ( flag -- ) my-if ." true " else ." false " then ;=20
> ^=20
>see my-if=20
>MY-IF (is IMMEDIATE)=20
>( 004C7A80 E89B23F4FF ) CALL 00409E20 IF=20
>( 004C7A85 C3 ) NEXT,=20
>( 6 bytes, 2 instructions )=20
> ok=20
>
>MY-IF is executing inside of a colon-word definition --- this is compilatio=
>n mode --- it should have worked.
>
>FIND has been sabotaged to provide a bad xt value for certain words; these =
>include IF and everything else listed in the ANS-Forth manual to have "inte=
>rpretation semantics undefined".=20
>
>The outer interpreter in VFX uses a different version of FIND that is not s=
>abotaged. This version of FIND provides a valid xt value for all words (inc=
>luding IF etc.). The outer interpreter gives this good xt value to EXECUTE =
>(because it is an immediate) word, and it works correctly.=20
Let's try your example the VFX way:
: my-if [ ' if ] literal compile, ; immediate ok
: ttt ( flag -- ) my-if ." true " else ." false " then ; ok
1 ttt true ok
0 ttt false ok
When I SEE INTERPRET, it says:
( 08058F9C E80FBDFFFF ) CALL 08054CB0 FIND
Different from the FIND you get?
' find hex . 8054CB0 ok
Apparently not.
What happens is that FIND in the text interpreter produces this xt for
FIND and reports that it is *not* immediate, the text interpreter then
calls "COMPILE,", and that then performs the compilation semantics.
Unusual, but it works for text-interpreting.
>The FIND provided to the user has been sabotaged to provide xt values for t=
>hese words (IF etc.) that will abort when given to EXECUTE. In the case of =
>gForth, FIND itself aborts when it is told to look up the xt of these words=
> (I noticed this in 2009 when my code aborted when it tried to tick semi-co=
>lon).
: c-if c" if" ; ok
c-if find . . 1 140737331022592 ok
c-if find . execute 1
:4: Interpreting a compile-only word
c-if find . >>>execute<<<
So FIND does not abort, reports an xt for the interpretation semantics
and an immediate word and a text interpreter using FIND would then
EXECUTE the xt, and would get the error at that point.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-23 10:50 +0000 |
| Message-ID | <5538ce3b.163707995@news.eternal-september.org> |
| In reply to | #38523 |
On Wed, 22 Apr 2015 20:05:28 -0700 (PDT), hughaguilar96@gmail.com wrote: >The outer interpreter in VFX uses a different version of FIND that is not s= >abotaged. Rubbish. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-24 11:59 -0700 |
| Message-ID | <f438ffbd-adf4-4ada-b244-240ed3d673ff@googlegroups.com> |
| In reply to | #38531 |
On Thursday, April 23, 2015 at 3:50:14 AM UTC-7, Stephen Pelc wrote: > On Wed, 22 Apr 2015 20:05:28 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >The outer interpreter in VFX uses a different version of FIND that is not s= > >abotaged. > > Rubbish. > > Stephen I conflated VFX and gForth, which was incorrect. It is gForth that provides the users with a sabotaged FIND that aborts for certain words (there must be a fully functional FIND used internally by the outer-interpreter however, in order for the outer-interpreter to work). In gForth, FIND special-cases certain words. In VFX, COMPILE, special-cases those words. Your FIND provides an xt that can't be executed --- this is despite the fact that we are supposed to be able to EXECUTE an xt (xt means: "execution token"). Your COMPILE, is special-casing these xt values, rather than compile them --- so you are exposing the implementation of your compiler to the user --- this is why my example (with MY-IF earlier) failed to work under VFX when it should have worked. The words being special-cased are those for which: "interpretation semantics for this word are undefined." Weirdly enough, you don't consistently special-case these. For example, IF is non-immediate but semicolon is immediate, so you have special-cased IF but not semicolon, although they both fall under the "ambiguous conditions" (section 4.1.2): "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." I think that both VFX and gForth are special-casing certain fundamental words in order to make it difficult for the user to write a cross-compiler. Both VFX and gForth can be defeated in their effort at obfuscation however. With the following code, we are put back on familiar ground (FIG-Forth, Forth-79 and Forth-83) again and everything once again works the way that it should. : +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate : ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate : ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate : >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate : abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate : begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate : do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate : does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate : else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate : exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate : I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate : leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate : literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate : loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate : r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate : r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate : recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate : repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate : s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate : then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate : unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate : until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate : while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate : [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate : ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate : [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate : 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate : 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate : 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate : ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate : again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate : c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate : case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate : compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate : endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate : endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate : of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate : [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate : 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate : fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate : (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate : locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate : ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate : ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate : cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate : cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate : sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-05-12 23:18 +0000 |
| Message-ID | <miu1on$g67$1@dont-email.me> |
| In reply to | #38523 |
hughaguilar96@gmail.com wrote: > All that pseudo-intellectual blather that Anton > Ertl was giving me, to the effect that I shouldn't > expect FIND to work for all the words (IF etc.), > was whitewash. Did FIND work for all words in some pre-ANS Forths? Specifically, did it work under UR/Forth?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-12 20:24 -0700 |
| Message-ID | <9b9fc06c-bda5-4e0a-acb1-6ccc7593b8e0@googlegroups.com> |
| In reply to | #39047 |
On Tuesday, May 12, 2015 at 4:19:56 PM UTC-7, WJ wrote: > hughaguilar96@gmail.com wrote: > > > All that pseudo-intellectual blather that Anton > > Ertl was giving me, to the effect that I shouldn't > > expect FIND to work for all the words (IF etc.), > > was whitewash. > > Did FIND work for all words in some pre-ANS Forths? > Specifically, did it work under UR/Forth? FIND always worked on all words. Also, the xt (called a cfa then) could be given to EXECUTE or COMPILE, and it would work. An xt for an immediate word should only be executed in or compiled into another immediate word --- this is easy to ensure however, because FIND tells you if the xt it is returning is of an immediate or non-immediate word --- most immediate words (IF, semicolon, etc.) will abort with an error message if used in interpretation mode, because that makes no sense and is an error. My SYNONYM SYNONYM-FAST and ALIAS would have worked fine without the disambiguifiers --- now they need the disambiguifiers to work, otherwise they abort with baffling error messages. All of ANS-Forth's ambiguity is gratuitous --- none of that existed in Forth-83 (UR/Forth was Forth-83; Ray Duncan gave up on Forth when ANS-Forth became the standard) --- there is no positive benefit to ambiguity. The fact that my disambiguifiers get rid of the ambiguity shows that the ambiguity is artificially imposed and is not inherent --- it is sabotage that can be fixed --- my disambiguifiers "jail-break" FIND from its artificial restrictions.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-24 08:56 -1000 |
| Message-ID | <H-udnfPCUtdnDKfInZ2dnUU7-cWdnZ2d@supernews.com> |
| In reply to | #37804 |
On 4/1/15 1:26 AM, Stephen Pelc wrote: ... > > I have been saying for a couple of years now that the ANS > standard's definition of compilation and interpretation is > incomprehensible for mere mortals such as myself. Every time > I reread the standard on this topic, the more I believe that > the standard's description of compilation and interpretation > needs a complete rewrite. > > In essence, Forth is a language of simplicity. Complexity such > as an optimising compiler is hidden. However, we now have a > standard in which the classic Forth interpreter loop is > broken according to some. We need to fix this by going back > to basics rather than putting bandages on bad prose. I agree that the description is pretty arcane, and encourage you to have a crack at it. Describing compilation and interpretation with precision but without constraining implementation is harder than it looks, and quite a lot of effort was put into it by a bunch of smart people, with the current result. I look forward to reading your version :-) Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-24 12:09 -0700 |
| Message-ID | <497a83f3-827b-4fe8-a04d-67079787bfac@googlegroups.com> |
| In reply to | #38576 |
On Friday, April 24, 2015 at 11:56:59 AM UTC-7, Elizabeth D. Rather wrote:
> On 4/1/15 1:26 AM, Stephen Pelc wrote:
> ...
> >
> > I have been saying for a couple of years now that the ANS
> > standard's definition of compilation and interpretation is
> > incomprehensible for mere mortals such as myself. Every time
> > I reread the standard on this topic, the more I believe that
> > the standard's description of compilation and interpretation
> > needs a complete rewrite.
> >
> > In essence, Forth is a language of simplicity. Complexity such
> > as an optimising compiler is hidden. However, we now have a
> > standard in which the classic Forth interpreter loop is
> > broken according to some. We need to fix this by going back
> > to basics rather than putting bandages on bad prose.
>
> I agree that the description is pretty arcane, and encourage you to have
> a crack at it. Describing compilation and interpretation with precision
> but without constraining implementation is harder than it looks, and
> quite a lot of effort was put into it by a bunch of smart people, with
> the current result.
>
> I look forward to reading your version :-)
>
> Cheers,
> Elizabeth
I look forward to you shutting your stupid mouth.
Your "bunch of smart people" on the ANS-Forth committee gave us the following as our current result:
3.4.4 Possible actions on an ambiguous condition
When an ambiguous condition exists, a system may take one or more of the following actions:
- ignore and continue;
- display a message;
- execute a particular word;
- set interpretation state and begin text interpretation;
- take other implementation-defined actions;
- take implementation-dependent actions.
The response to a particular ambiguous condition need not be the same under all circumstances.
Anyway, I have defeated your effort at making FIND ambiguous. This ANS-Forth code disambiguifies the situation:
: +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate
: ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate
: ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate
: >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate
: abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate
: begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate
: do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate
: does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate
: else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate
: exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate
: I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate
: if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate
: J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate
: leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate
: literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate
: loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate
: postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate
: r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate
: r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate
: recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate
: repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate
: s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate
: then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate
: unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate
: until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate
: while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate
: [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate
: ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate
: [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate
: 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate
: 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate
: 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate
: ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate
: again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate
: c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate
: case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate
: compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate
: endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate
: endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate
: of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate
: [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate
: 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate
: fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate
: (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate
: locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate
: ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate
: ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate
: cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate
: cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate
: sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-24 22:29 +0100 |
| Message-ID | <mheci8$rt8$1@dont-email.me> |
| In reply to | #38579 |
on 24/04/2015 20:09:27, hurge wrote: > > I look forward to you shutting your stupid mouth. I look forward to hearing that you've grown up.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2015-06-15 17:54 +0000 |
| Message-ID | <mln3gq$o9p$1@dont-email.me> |
| In reply to | #38576 |
Elizabeth Rather wrote:
> I agree that the description is
> pretty arcane, and encourage you
> to have a crack at it. Describing
> compilation and interpretation
> with precision but without
> constraining implementation is
> harder than it looks, and quite a
> lot of effort was put into it by
> a bunch of smart people, with the
> current result.
Let's try to read between the lines:
Gauche Scheme:
(define words (string-split
"I agree that the description is pretty
arcane, and encourage you to have a crack at
it. Describing compilation and
interpretation with precision but without
constraining implementation is harder than
it looks, and quite a lot of effort was put
into it by a bunch of smart people, with the
current result."
#/[\s.,]+/))
(string-join (map (cut ~ words <>) '(0 5 33 46)))
===>
"I is quite smart"
--
"A woman's place is in the home." --- Wise old saying
[toc] | [prev] | [next] | [standalone]
| From | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| Date | 2015-04-02 09:04 -0700 |
| Message-ID | <5dc6fc7f-df1a-48c5-8d9c-4e1547276ab5@googlegroups.com> |
| In reply to | #37787 |
On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote: > Actually, I have already figured out a way to work around this bug. Because you have your own Forth written in Flat Assember, maybe you can just use that Forth and move on? Jason
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-02 21:04 -0700 |
| Message-ID | <2788967d-9628-4e36-98fa-b83432b84a92@googlegroups.com> |
| In reply to | #37841 |
On Thursday, April 2, 2015 at 9:04:24 AM UTC-7, Jason Damisch wrote: > On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote: > > > Actually, I have already figured out a way to work around this bug. When I said that I had figured out a way to work around the bug, I meant that I did this in ANS-Forth --- I save the name of the word and so the synonym (of an immediate word) can EVALUATE it --- but this is late-binding, which is a problem. Saving the xt so the synonym (of an immediate word) can EXECUTE it is the correct way to implement SYNONYM (this is the way that it has been implemented for about 30 years, ever since the first implementation came out in "Forth Dimensions") --- but this doesn't work under VFX, which is why I say that VFX has a bug. ANS-Forth is failing badly. While writing my novice-package, I have found bugs in every ANS-Forth compiler (SwiftForth, Win32Forth, Gforth, and now VFX). Also, the standard itself is screwed up --- my novice-package is composed almost entirely of work-arounds for the bugs in the standard --- none of this stuff is good enough to be used in commercial work where the programmer has a deadline. > Because you have your own Forth written in Flat Assember, maybe you can > just use that Forth and move on? If my Forth is not standard, then I can no longer claim to be a Forth programmer --- this is very bad for me, because I've been a Forth programmer for 30 years and Forth programming is something that I'm good at. Jason, you are making a big mistake by accepting a language standard that is owned by a vendor --- you can't claim to be a Forth programmer either, unless you buy their product --- this is corruption of the language-standard concept. Using Gforth will not make you a Forth programmer --- Gforth is incompatible with both SwiftForth and VFX (although not in the same way). With Forth-200x, we are rapidly getting to the point where there effectively is no Forth language-standard at all, but if you don't use SwiftForth or VFX then you are denounced as being non-standard and not a Forth programmer at all --- this is despite the fact that SwiftForth and VFX are not compatible with each other --- ultimately, Leon Wagner and Stephen Pelc are on the Forth-200x committee and they say who is a Forth programmer and who isn't. Anyway, Jason, why do you care? You are a website programmer; Forth is just a hobby for you. If you brown-nose the Forth-200x committee, they will let you claim to be a Forth programmer, and if you stop brown-nosing them, then you will stop being a Forth programmer --- but you're not writing Forth programs anyway, so what difference would it make one way or the other?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-03 10:48 +0000 |
| Message-ID | <551e6ffd$0$21311$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #37864 |
In article <2788967d-9628-4e36-98fa-b83432b84a92@googlegroups.com>, <hughaguilar96@gmail.com> wrote: >On Thursday, April 2, 2015 at 9:04:24 AM UTC-7, Jason Damisch wrote: >> On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote: >> >> > Actually, I have already figured out a way to work around this bug. > >When I said that I had figured out a way to work around the bug, I meant >that I did this in ANS-Forth --- I save the name of the word and so the >synonym (of an immediate word) can EVALUATE it --- but this is >late-binding, which is a problem. We already have been over this. You can't define SYNONYM in ISO Forth. It requires carnal knowledge. So how would you call some one who still tries? Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
Page 15 of 17 — ← Prev page 1 … 13 14 [15] 16 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web