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 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-04-06 16:44 -1000 |
| Message-ID | <DY6dnXg4qvUF2b7InZ2dnUU7-YOdnZ2d@supernews.com> |
| In reply to | #38030 |
On 4/6/15 4:07 PM, Rod Pemberton wrote: > On Mon, 06 Apr 2015 09:56:54 -0400, Anton Ertl > <anton@mips.complang.tuwien.ac.at> wrote: >> hughaguilar96@gmail.com writes: >>> On Sunday, April 5, 2015 at 3:50:03 AM UTC-7, Anton Ertl wrote: > >>>> Immediacy is not the issue, the lack of defined interpretation >>>> semantics is. You can tick immediate words with intepretation >>>> semantics like ( and \ or user-defined immediate words all day long, >>>> and the result is defined by the standard. >>> >>> So, what attribute does IF have other than immediacy? >>> you said that immediacy is not the issue --- so what is the issue? >> >> The lack of defined interpretation semantics. >> >> BTW, the standard does not define IF to be immediate. > > Are you saying ANS Forth excludes a Forth from being interpreted? > > 1) Please explain how IF can execute within a colon-definition > for an interpreted Forth if the word isn't marked IMMEDIATE . There's a little confusion here about the phrase "interpreted Forth." The classical "interpreted, threaded code" or ITC implementation refers to what is compiled (successive pointers to words to be executed), not how the compiler does its work. Even before ANS Forth, there were multiple approaches to achieving this. Marking words IMMEDIATE was the commonest, but there were other ways, such as defining compiler directives in special vocabularies. For that matter, some compile-to-code implementations mark compiler directives as IMMEDIATE, although that isn't required, either. Properly speaking, the only "interpretation" in any Forth is done by the text interpreter, processing user commands, source, etc. The terms "inner interpreter" and "address interpreter" are pretty obsolete. > 2) Please explain how IF can have separate compilation and > interpretation semantics for an interpreted Forth when IF needs > to marked as IMMEDIATE to function within a colon-definition? IF doesn't need to have any interpretation semantics. Its essential action occurs at compile time. It just needs to be recognized and executed by the compiler, to compile whatever code, pointers, etc., are necessary for it to do its runtime job. > Remember, you only have two STATEs, interpret and compile, and > immediacy via IMMEDIATE . There is no compile-only flag, etc, > available to you for an interpreted Forth. Not necessarily. As noted above, from earliest times there were ways of managing compiler directives, of which "compile only" flags, separate vocabularies, and other strategies are examples. > I.e., claiming that "Interpretation semantics for this word > are undefined" means that interpretation semantics can't be > defined is clearly wrong. That would break all, or most, > interpreted Forths, I think. Historically, interpretation > semantics were defined for all such words. No, it means that you can't *count on* there being any interpretation semantics, and if there are, there's no specification as to what they can and cannot do. That's what "undefined" means. There have been Forths (including ITC Forths) that let you type conditional phrases at the command line and execute them, Forths that issue an error message (defined nowadays as THROW code -14) if you try to do that, or other behaviors. Don't make the mistake of thinking that the way Fig Forth worked, or the way Brodie described things, was the only way ITC Forths worked! Chuck himself went through numerous iterations on this design issue. 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-07 11:09 +0000 |
| Message-ID | <5523b95e.948785834@news.eternal-september.org> |
| In reply to | #38030 |
On Mon, 06 Apr 2015 22:07:21 -0400, "Rod Pemberton" <bork@lllljunkqwer.cpm> wrote: >1) Please explain how IF can execute within a colon-definition >for an interpreted Forth if the word isn't marked IMMEDIATE . In VFX Forth, compilation is performed by COMPILE, and execution by EXECUTE. A header entry in each word determines whether it has a special compiler. When IF is encountered during compilation its special compiler runs. The same is true for DUP and SWAP. With this scheme it is possible (and we did so) build a Forth with no IMMEDIATE words at all. Although nobody noticed for practical reasons, it was non-standard and we finally made IMMEDIATE those words that have to be IMMEDIATE for standards compliance. >2) Please explain how IF can have separate compilation and >interpretation semantics for an interpreted Forth when IF needs >to marked as IMMEDIATE to function within a colon-definition? You are ignoring the dictionary structure that we use. The VFX Forth manual discusses this in some detail. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-07 14:49 +0000 |
| Message-ID | <2015Apr7.164952@mips.complang.tuwien.ac.at> |
| In reply to | #38030 |
"Rod Pemberton" <bork@lllljunkqwer.cpm> writes:
>On Mon, 06 Apr 2015 09:56:54 -0400, Anton Ertl
><anton@mips.complang.tuwien.ac.at> wrote:
>> hughaguilar96@gmail.com writes:
>>> On Sunday, April 5, 2015 at 3:50:03 AM UTC-7, Anton Ertl wrote:
>
>>>> Immediacy is not the issue, the lack of defined interpretation
>>>> semantics is. You can tick immediate words with intepretation
>>>> semantics like ( and \ or user-defined immediate words all day long,
>>>> and the result is defined by the standard.
>>>
>>> So, what attribute does IF have other than immediacy?
>>> you said that immediacy is not the issue --- so what is the issue?
>>
>> The lack of defined interpretation semantics.
>>
>> BTW, the standard does not define IF to be immediate.
>
>Are you saying ANS Forth excludes a Forth from being interpreted?
No. I think what you mean is whether the standard excludes
traditional single-xt-with-immediate-flag implementations. The answer
for that is also "no".
>1) Please explain how IF can execute within a colon-definition
>for an interpreted Forth if the word isn't marked IMMEDIATE .
That's up to the implementation. On a traditional
single-xt-with-immediate-flag implementation, sure, marking IF as
immediate is the only way to implement it, and the standard allows
that; it just does not prescribe that. Other implementations don't
need an immediate flag for IF, e.g. cmForth.
>2) Please explain how IF can have separate compilation and
>interpretation semantics for an interpreted Forth when IF needs
>to marked as IMMEDIATE to function within a colon-definition?
The premise is wrong, but anyway: If you have a traditional
single-xt-with-immediate-flag system, you cannot implement separate
compilation and interpretation semantics (some try to fake it with
STATE-smart words, but that does not behave properly when ticked or
POSTPONEd). But with a different kind of implementation, you can.
>Remember, you only have two STATEs, interpret and compile, and
>immediacy via IMMEDIATE . There is no compile-only flag, etc,
>available to you for an interpreted Forth.
>
>I.e., claiming that "Interpretation semantics for this word
>are undefined" means that interpretation semantics can't be
>defined is clearly wrong. That would break all, or most,
>interpreted Forths, I think. Historically, interpretation
>semantics were defined for all such words.
A standard-compliant Forth system can define interpretation semantics
for IF. The standard does not define what they are, though, so
standard programs cannot make use of the interpretation semantics of
IF.
- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-08 01:58 +0100 |
| Message-ID | <mg1ud4$cc8$1@dont-email.me> |
| In reply to | #38046 |
on 07/04/2015 15:49:49, Anton wrote:
> "Rod Pemberton" <bork@lllljunkqwer.cpm> writes:
>>On Mon, 06 Apr 2015 09:56:54 -0400, Anton Ertl
>><anton@mips.complang.tuwien.ac.at> wrote:
>>> hughaguilar96@gmail.com writes:
>>>> On Sunday, April 5, 2015 at 3:50:03 AM UTC-7, Anton Ertl wrote:
>>
>>>>> Immediacy is not the issue, the lack of defined interpretation
>>>>> semantics is. You can tick immediate words with intepretation
>>>>> semantics like ( and \ or user-defined immediate words all day long,
>>>>> and the result is defined by the standard.
>>>>
>>>> So, what attribute does IF have other than immediacy?
>>>> you said that immediacy is not the issue --- so what is the issue?
>>>
>>> The lack of defined interpretation semantics.
>>>
>>> BTW, the standard does not define IF to be immediate.
>>
>>Are you saying ANS Forth excludes a Forth from being interpreted?
>
> No. I think what you mean is whether the standard excludes
> traditional single-xt-with-immediate-flag implementations. The answer
> for that is also "no".
>
>>1) Please explain how IF can execute within a colon-definition
>>for an interpreted Forth if the word isn't marked IMMEDIATE .
>
> That's up to the implementation. On a traditional
> single-xt-with-immediate-flag implementation, sure, marking IF as
> immediate is the only way to implement it, and the standard allows
> that; it just does not prescribe that. Other implementations don't
> need an immediate flag for IF, e.g. cmForth.
>
>>2) Please explain how IF can have separate compilation and
>>interpretation semantics for an interpreted Forth when IF needs
>>to marked as IMMEDIATE to function within a colon-definition?
>
> The premise is wrong, but anyway: If you have a traditional
> single-xt-with-immediate-flag system, you cannot implement separate
> compilation and interpretation semantics (some try to fake it with
> STATE-smart words, but that does not behave properly when ticked or
> POSTPONEd). But with a different kind of implementation, you can.
An example from my Forth, which Anton helped me formulate some years ago
(note some of the implementation details have been simplified here).
: compiles> ( c: -- xt-of-I )
( internal stuff to provide compilation semantics )
( at compile time leaves the interpretation xt on the stack )
( terminates any DOES> )
... ;
: if ( c: -- orig ) \ branch on fl=false
( fl -- )
-14 throw
compiles> drop postpone ?branch mark> mark-if ;
An IMMEDIATE is effectively a modified standard xt, so adding IMMEDIATE
: \ source >in ! drop ; immediate
turns the definition into
: \ source >in ! drop
compiles> execute ;
When IF is interpreted, it does the interpretation (standard part of the
definition) code; when compiled, the COMPILES> code. The action is
controlled by [ and ] which use a defered word to select either
interpretation or compilation semantics. There is a STATE variable, but
it is purely informative and could be eliminated as none of the code
requires it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-20 23:21 -0700 |
| Message-ID | <4a7e3e98-593e-47c9-be62-3b5df829094a@googlegroups.com> |
| In reply to | #37960 |
On Sunday, April 5, 2015 at 3:50:03 AM UTC-7, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >On Friday, April 3, 2015 at 1:58:49 PM UTC-7, Anton Ertl wrote: > >> hughaguilar96@gmail.com writes: > >> |6.1.0070 ' tick CORE > >> |=20 > >> |( "<spaces>name" -- xt ) > >> | > >> |Skip leading space delimiters. Parse name delimited by a space. Find > >> |name and return xt, the execution token for name. An ambiguous > >> |condition exists if name is not found. *When interpreting, ' xyz > >> |EXECUTE is equivalent to xyz.* > >>=20 > >> Emphasis mine. I have an informal answer from a Forth-94 TC member > >> that the empasised sentence implies that a standard program cannot > >> tick words without interpretation semantics. So when you ' IF, the > >> system can do whatever it likes, e.g., report an error, give you the > >> xt of a word that produces an error on execution, give you the xt of a > >> word that represents the compilation semantics of IF, or something > >> else. > > > >At the very beginning of this thread, I said: > >"This is the same bug that I previously discovered in Gforth when writing M= > >ACRO: (the ; doesn't have an xt). Now in VFX I find that IF has an xt, but = > >it doesn't work." > > > >This is essentially what you are saying now. If you tick or FIND an immedia= > >te word, you may get an abort (what happened when I ticked ; in Gforth), yo= > >u may get an xt of a word that aborts on execution (what happened when I ti= > >cked IF in VFX), or you may get mushrooms growing on your ass --- pretty mu= > >ch anything is ANS-Forth compliant except for the possibility that the xt w= > >hen executed does what the word does when executed. You are the chairperson= > > of the Forth-200x committee, but you are totally focused on telling me wha= > >t I can't do, and telling me that the xt of an immediate word became meanin= > >gless and that I should have known this. > > Immediacy is not the issue, the lack of defined interpretation > semantics is. You can tick immediate words with intepretation > semantics like ( and \ or user-defined immediate words all day long, > and the result is defined by the standard. > > >BTW: Who was the "Forth-94 TC member" who interpreted this sentence, "When = > >interpreting, ' xyz EXECUTE is equivalent to xyz." to mean that it is impos= > >sible in ANS-Forth to obtain a working xt of an immediate word? This seems = > >like a bit of a stretch to interpret this one sentence in such a way as to = > >make meaningless the xt of every immediate word (why does FIND return an xt= > > for an immediate word if it is meaningless, and why doesn't the documentat= > >ion for FIND mention that it is returning an unusable xt?) > > The TC member was Loring Craymer. But looking at the old mails, the > TC also pointed me to: > > |4.1.2 Ambiguous conditions > |[...] > |attempting to obtain the execution token, (e.g., with 6.1.0070 ', > |6.1.1550 FIND, etc.) of a definition with undefined interpretation > |semantics; > > And interpreting that to mean that a standard program cannot get the > xt of a word without interpretation semantics is not at all a stretch. > > Concerning FIND, returning the not-found result when FINDing a word > without interpretation semantcs in interpretation state would also be > an option; that's what cmForth did, and supporting such systems was > certainly the intent of the Forth-94 TC. > > I guess you would not be any happier if ' IF reported "undefined word" > and if C" IF" FIND in interpretation state gave you the not-found > result. > > - anton 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!
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-21 02:10 -0700 |
| Message-ID | <9aec2861-bc77-47ed-a819-acf2830aee7f@googlegroups.com> |
| In reply to | #38430 |
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.
It's probably written something like this in VFX:
: IF
STATE @ IF
['] (IF) COMPILE,
ELSE
TRUE ABORT" Compilation only"
THEN ; IMMEDIATE
Or something like that. What you want, is the XT of (IF) or whatever
its called in VFX. It may or not exist, depending on how VFX is
factored. I'll wager that it most certainly does exist. COMPILE,
may get you the correct behaviour, as it's specifically designed to
append the *execution semantics* of a word.
Note that (irony) COMPILE, has undefined interpretation semantics ;-)
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-21 10:41 +0000 |
| Message-ID | <55362790.86681253@news.eternal-september.org> |
| In reply to | #38433 |
On Tue, 21 Apr 2015 02:10:20 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: >It's probably written something like this in VFX: > >: IF > STATE @ IF=20 > ['] (IF) COMPILE, > ELSE=20 > TRUE ABORT" Compilation only" > THEN ; IMMEDIATE > >Or something like that. What you want, is the XT of (IF) or whatever >its called in VFX. It may or not exist, depending on how VFX is=20 >factored. I'll wager that it most certainly does exist. Don't get trapped by someone else's assumptions. The VFX version of IF is nothing like your or Hugh's assumptions. : IF \ C: -- orig ; Run: x -- ; 6.1.1700 NoInterp ; comp: ( xt -- ) drop s_?br>, ?checking if 2 then ; For explanations, RTFM. I really do get tired of other people telling me how VFX works. Yes, there is a conceptual similarity between the actual code and your code, but there is a set of other design decisions between assumption and reality. 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-21 13:31 +0100 |
| Message-ID | <mh5fts$6r2$1@dont-email.me> |
| In reply to | #38436 |
on 21/04/2015 11:41:51, wrote:
> On Tue, 21 Apr 2015 02:10:20 -0700 (PDT), Mark Wills
> <markwills1970@gmail.com> wrote:
>
>>It's probably written something like this in VFX:
>>
>>: IF
>> STATE @ IF=20
>> ['] (IF) COMPILE,
>> ELSE=20
>> TRUE ABORT" Compilation only"
>> THEN ; IMMEDIATE
>>
>>Or something like that. What you want, is the XT of (IF) or whatever
>>its called in VFX. It may or not exist, depending on how VFX is=20
>>factored. I'll wager that it most certainly does exist.
>
> Don't get trapped by someone else's assumptions. The VFX version
> of IF is nothing like your or Hugh's assumptions.
>
>: IF \ C: -- orig ; Run: x -- ; 6.1.1700
> NoInterp
> ;
> comp: ( xt -- ) drop s_?br>, ?checking if 2 then ;
>
> For explanations, RTFM. I really do get tired of other people
> telling me how VFX works. Yes, there is a conceptual similarity
> between the actual code and your code, but there is a set of
> other design decisions between assumption and reality.
>
> Stephen
>
For my Forth, the xt of IF is -13 THROW. There's nothing else you can
get.
: if ( c: -- orig ) \ branch on fl=false
( x -- )
only-compiles>
postpone ?bra mark> mark-if ;
There is no effing manual to read in my case.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-21 06:00 -0700 |
| Message-ID | <0cc25b42-2951-4358-9695-c8e15087753b@googlegroups.com> |
| In reply to | #38441 |
On Tuesday, 21 April 2015 13:31:53 UTC+1, Alex McDonald wrote: > on 21/04/2015 11:41:51, wrote: > > On Tue, 21 Apr 2015 02:10:20 -0700 (PDT), Mark Wills > > <> wrote: > > > >>It's probably written something like this in VFX: > >> > >>: IF > >> STATE @ IF=20 > >> ['] (IF) COMPILE, > >> ELSE=20 > >> TRUE ABORT" Compilation only" > >> THEN ; IMMEDIATE > >> > >>Or something like that. What you want, is the XT of (IF) or whatever > >>its called in VFX. It may or not exist, depending on how VFX is=20 > >>factored. I'll wager that it most certainly does exist. > > > > Don't get trapped by someone else's assumptions. The VFX version > > of IF is nothing like your or Hugh's assumptions. > > > >: IF \ C: -- orig ; Run: x -- ; 6.1.1700 > > NoInterp > > ; > > comp: ( xt -- ) drop s_?br>, ?checking if 2 then ; > > > > For explanations, RTFM. I really do get tired of other people > > telling me how VFX works. Yes, there is a conceptual similarity > > between the actual code and your code, but there is a set of > > other design decisions between assumption and reality. > > > > Stephen > > > > For my Forth, the xt of IF is -13 THROW. There's nothing else you can > get. > > : if ( c: -- orig ) \ branch on fl=false > ( x -- ) > only-compiles> > postpone ?bra mark> mark-if ; > > There is no effing manual to read in my case. Do you mean when state=0 then only-compiles> does a -13 throw? I see IF is not immediate. How does it execute during the compilation of a definition (just being nosey!)?
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-04-21 14:09 +0100 |
| Message-ID | <mh5i59$f16$1@dont-email.me> |
| In reply to | #38442 |
on 21/04/2015 14:00:23, Mark Wills wrote: > On Tuesday, 21 April 2015 13:31:53 UTC+1, Alex McDonald wrote: >> on 21/04/2015 11:41:51, wrote: >> > On Tue, 21 Apr 2015 02:10:20 -0700 (PDT), Mark Wills >> > <> wrote: >> > >> >>It's probably written something like this in VFX: >> >> >> >>: IF >> >> STATE @ IF=20 >> >> ['] (IF) COMPILE, >> >> ELSE=20 >> >> TRUE ABORT" Compilation only" >> >> THEN ; IMMEDIATE >> >> >> >>Or something like that. What you want, is the XT of (IF) or whatever >> >>its called in VFX. It may or not exist, depending on how VFX is=20 >> >>factored. I'll wager that it most certainly does exist. >> > >> > Don't get trapped by someone else's assumptions. The VFX version >> > of IF is nothing like your or Hugh's assumptions. >> > >> >: IF \ C: -- orig ; Run: x -- ; 6.1.1700 >> > NoInterp >> > ; >> > comp: ( xt -- ) drop s_?br>, ?checking if 2 then ; >> > >> > For explanations, RTFM. I really do get tired of other people >> > telling me how VFX works. Yes, there is a conceptual similarity >> > between the actual code and your code, but there is a set of >> > other design decisions between assumption and reality. >> > >> > Stephen >> > >> >> For my Forth, the xt of IF is -13 THROW. There's nothing else you can >> get. >> >> : if ( c: -- orig ) \ branch on fl=false >> ( x -- ) >> only-compiles> >> postpone ?bra mark> mark-if ; >> >> There is no effing manual to read in my case. > > Do you mean when state=0 then only-compiles> does a -13 throw? > > I see IF is not immediate. How does it execute during the compilation > of a definition (just being nosey!)? > Actually, there's a part manual, since Anton Ertl and I discussed this some time ago, and I used these ideas in my compiler. https://www.complang.tuwien.ac.at/forth/header-ideas.html
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-04-22 10:59 +0200 |
| Message-ID | <86bnigiln8.fsf@vps34351.public.cloudvps.com> |
| In reply to | #38436 |
stephen@mpeforth.com (Stephen Pelc) writes: > The VFX version of IF is nothing like your or Hugh's assumptions. > > : IF \ C: -- orig ; Run: x -- ; 6.1.1700 > NoInterp > ; > comp: ( xt -- ) drop s_?br>, ?checking if 2 then ; What do you get from : TICK-IF ] C" IF" FIND POSTPONE [ ; ?
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-22 11:41 +0000 |
| Message-ID | <553788e6.80423523@news.eternal-september.org> |
| In reply to | #38476 |
On Wed, 22 Apr 2015 10:59:23 +0200, Lars Brinkhoff <lars.spam@nocrew.org> wrote: >stephen@mpeforth.com (Stephen Pelc) writes: >> The VFX version of IF is nothing like your or Hugh's assumptions. >> >> : IF \ C: -- orig ; Run: x -- ; 6.1.1700 >> NoInterp >> ; >> comp: ( xt -- ) drop s_?br>, ?checking if 2 then ; > >What do you get from > >: TICK-IF ] C" IF" FIND POSTPONE [ ; VFX Forth for Windows IA32 © MicroProcessor Engineering Ltd, 1998-2014 Version: 4.71 [build 3529] Build date: 30 October 2014 Free dictionary = 7550062 bytes [7373kb] : TICK-IF ] C" IF" FIND POSTPONE [ ; ok ok ok dis tick-if TICK-IF ( 004CABC0 E8C36EF4FF ) CALL 00411A88 ] ( 004CABC5 E81A73F4FF ) CALL 00411EE4 (C") "IF" ( 004CABD0 E85738F4FF ) CALL 0040E42C FIND ( 004CABD5 E88A6EF4FF ) CALL 00411A64 [ ( 004CABDA C3 ) NEXT, ( 27 bytes, 5 instructions ) ok 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 | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2015-04-22 14:13 +0200 |
| Message-ID | <86r3rcgy3y.fsf@vps34351.public.cloudvps.com> |
| In reply to | #38491 |
stephen@mpeforth.com (Stephen Pelc) writes: >>What do you get from >>: TICK-IF ] C" IF" FIND POSTPONE [ ; > dis tick-if Sorry, perhaps I should have written more clearly "what is the result of running TICK-IF?". Or even, what is the xt you get for IF when you run FIND in compilation mode? And what happens when you EXECUTE that xt in compilation mode? Just curious how your special compilation semantics works with the legacy FIND.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-22 14:06 +0000 |
| Message-ID | <2015Apr22.160616@mips.complang.tuwien.ac.at> |
| In reply to | #38492 |
Lars Brinkhoff <lars.spam@nocrew.org> writes:
>stephen@mpeforth.com (Stephen Pelc) writes:
>>>What do you get from
>>>: TICK-IF ] C" IF" FIND POSTPONE [ ;
>> dis tick-if
>
>Sorry, perhaps I should have written more clearly "what is the result of
>running TICK-IF?".
tick-if . . -1 134548532 ok
' if . 134548532 ok
As you see, VFX delivers the same result.
OTOH, in Gforth 0.7.0, you get:
tick-if . . 1 140737331121848 ok
' if
:3: Cannot tick compile-only word (try COMP' ... DROP)
s" if" find-name name>int . 140737331067552 ok
As you can see, in Gforth we can get two different xts; the one coming
from TICK-IF performs the compilation semantics when EXECUTEd, the one
coming from NAME>INT gives you an error when EXECUTEd.
VFX has only one xt for every word. EXECUTEing that xt produces the
interpretation semantics of the word, while COMPILE,in it produces the
compilation semantics. That's the wrong way to do it, because
COMPILE, is no longer equivalent to
: compile, postpone literal postpone execute ;
but the cases where the difference matters are very special and
contrived and non-standard until now. If we ever standardized COMP:
or somesuch, the difference would matter.
- 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-22 15:42 +0000 |
| Message-ID | <5537bf13.94292479@news.eternal-september.org> |
| In reply to | #38498 |
On Wed, 22 Apr 2015 14:06:16 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >VFX has only one xt for every word. EXECUTEing that xt produces the >interpretation semantics of the word, while COMPILE,in it produces the >compilation semantics. That's the wrong way to do it, because >COMPILE, is no longer equivalent to > >: compile, postpone literal postpone execute ; > >but the cases where the difference matters are very special and >contrived and non-standard until now. If we ever standardized COMP: >or somesuch, the difference would matter. The ANS specification uses an xt as an opaque type that is the single point of reference to a word. It was designed to avoid the raft of dictionary navigation words required for effective use of FIG and Forth-83 systems. The permission to return different xts in interpretation and compilation states was a concession to cmForth. Exploiting this concession is itself a mistake im my opinion because it reopens the box that xts were designed to keep shut. 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 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. 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-22 15:57 +0000 |
| Message-ID | <5537c4dc$0$21238$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38504 |
In article <5537bf13.94292479@news.eternal-september.org>, Stephen Pelc <stephen@mpeforth.com> wrote: >On Wed, 22 Apr 2015 14:06:16 GMT, anton@mips.complang.tuwien.ac.at >(Anton Ertl) wrote: > >>VFX has only one xt for every word. EXECUTEing that xt produces the >>interpretation semantics of the word, while COMPILE,in it produces the >>compilation semantics. That's the wrong way to do it, because >>COMPILE, is no longer equivalent to >> >>: compile, postpone literal postpone execute ; >> >>but the cases where the difference matters are very special and >>contrived and non-standard until now. If we ever standardized COMP: >>or somesuch, the difference would matter. > >The ANS specification uses an xt as an opaque type that is the single >point of reference to a word. It was designed to avoid the raft of >dictionary navigation words required for effective use of FIG and >Forth-83 systems. > >The permission to return different xts in interpretation and >compilation states was a concession to cmForth. Exploiting >this concession is itself a mistake im my opinion because it >reopens the box that xts were designed to keep shut. > >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 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. I agree wholeheartedly. I wished 'word token' had been chosen. In ciforth I started from a dictionary entry address that is one to one with Forth words. Those can be used as "execution tokens". (Then I introduced denotations. Although denotations result in different stack effects, all have the property that in compilation mode the effect is compiling the same stack effect as is executed during execution. That sounds complicated, but it amounts to saying that they behave like numbers.) I can't see why it would be advantageous to get rid of STATE, especially not if must offset the disadvantage of having different sets of tokens. > >Stephen 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-22 16:43 +0000 |
| Message-ID | <2015Apr22.184328@mips.complang.tuwien.ac.at> |
| In reply to | #38504 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Wed, 22 Apr 2015 14:06:16 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>VFX has only one xt for every word. EXECUTEing that xt produces the
>>interpretation semantics of the word, while COMPILE,in it produces the
>>compilation semantics. That's the wrong way to do it, because
>>COMPILE, is no longer equivalent to
>>
>>: compile, postpone literal postpone execute ;
>>
>>but the cases where the difference matters are very special and
>>contrived and non-standard until now. If we ever standardized COMP:
>>or somesuch, the difference would matter.
>
>The ANS specification uses an xt as an opaque type that is the single
>point of reference to a word. It was designed to avoid the raft of
>dictionary navigation words required for effective use of FIG and
>Forth-83 systems.
>
>The permission to return different xts in interpretation and
>compilation states was a concession to cmForth. Exploiting
>this concession is itself a mistake im my opinion because it
>reopens the box that xts were designed to keep shut.
Abolish >BODY now! Just joking.
While the fig-Forth way to navigate in a header is messy, it does not
cause problems comparable to those of STATE-smart words (i.e., bugs
that appear far from the origin).
But actually comparing the issue to fig-Forth header navigation is a
red herring in several ways:
1) fig-Forth did not solve the problem of STATE-smart words.
2) Forth-94 does not provide the capabilities that the fig-Forth
header words provide. Link field, name field, code field, parameter
field? The only part of that that Forth-94 has to get to what
fig-Forth called the parameter field, and Forth-94 contains an extra
word for that: >BODY. If they really wanted to avoid all that
navigation, they would have eliminated >BODY, too, and used the body
address as the single point of reference.
We have the capabilities partly in Forth-2012: TRAVERSE-WORDLIST
provides part of what could be done with the link field, NAME>STRING
gives us the name field, NAME>INT (and NAME>COMP) correspond to
getting to the code field.
Anyway, the origin of the problem is words like S", TO, IS, and
ACTION-OF. When they are text-interpreted, you want them to do the
parsing at text-interpretation time, and then something at run-time
(and maybe some storage in between). That does not fit the classical
Forth model of having a single xt.
People have worked around that with STATE-smart words, but that
produces state-dependent behaviour when these words are ticked or
POSTPONEd, which leads to unintended behaviour in some cases far from
the cause of the problem.
In Gforth these words have one xt representing the interpretation
semantics and one xt for compilation semantics.
In VFX you solve that problem by noticing that the classical text
interpreter COMPILE,s words not marked as immediate in compile state,
and EXECUTEs them in interpretation state.
So you hang the two semantics of words like S" on one xt, the
interpretation semantics is performed by EXECUTE, the compilation
semantics by COMPILE,. That's a good idea for words with default
compilation semantics (i.e., normal words like +), but not for words
like S", because it breaks the relation between EXECUTE and COMPILE,
i.e., COMPILE, being equivalent to
: compile, postpone literal postpone execute ;
This equivalence is used in, e.g., various OOF packages (dynamic
binding EXECUTEs, early binding COMPILE,s), but fortunately you don't
use the xt of S" etc. in that context, and ticking S" is rare in
general, so the problem does not occur in practice for now.
The long-term solution IMO is to get rid of words like S", i.e., have
only words with one semantics. For replacing these parsing words
recognizers may be the solution.
>There are other problems in the gForth perspective, especially
>in that you can't write a full Forth text interpreter in the
>classical model.
Incorrect and unsubstantiated claims...is your name Hugh Aguilar?
>I know that you and I are not going to agree on this topic, but
>when you raise such issues, you should at least acknowledge
>that there are differences of opinion on the topic.
I rely on you making that point:-).
>The Forth
>202x technical committee should start by having a long
>discussion about what compilation in Forth actually involves.
Fine with me, although somewhat sceptical given the way earlier
discussions have gone.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-24 05:35 +0200 |
| Message-ID | <mhcdl1$qh$1@dont-email.me> |
| In reply to | #38510 |
Anton Ertl wrote: > So you hang the two semantics of words like S" on one xt, the > interpretation semantics is performed by EXECUTE, the compilation > semantics by COMPILE,. That's a good idea for words with default > compilation semantics (i.e., normal words like +), but not for words > like S", because it breaks the relation between EXECUTE and COMPILE, > i.e., COMPILE, being equivalent to > > : compile, postpone literal postpone execute ; IIRC, the result of our last discussion was that this equivalence doesn't hold for compile-only words, because you aren't allowed to tick them. As you derive this equivalence from ' foo execute = interpretation semantics. If you can't tick foo in a standard way, ' foo execute = undefined; and that certainly beaks the compile, equivalence, too. Neither does it apply to words with special compilation semantics like S" or TO, because we added these words to the list of "untickable words". Leaves normal and deliberately immediate words like ( or \ for which this equivalence can hold. FIND can return an xt for an untickable word, but that xt is not necessarily the one for which the ' foo execute equivalence holds, so the compile,- equivalence also can't work. If you have problems remembering the discussion, I've video-taped it. > This equivalence is used in, e.g., various OOF packages (dynamic > binding EXECUTEs, early binding COMPILE,s), but fortunately you don't > use the xt of S" etc. in that context, and ticking S" is rare in > general, so the problem does not occur in practice for now. And we have managed to make sure the problem can't occur in a standard program for the Forth-2012 standard. By making all those words that won't hold that equivalence untickable. As I'm fully for tightening up the spec, we can tighten it up differently. Usually, thise OOF package use :NONAME xts for method implementations, and :NONAME-xts work. People who use SET-COMPILER on their xts create non- standard programs, and they probably know what they do (different early/late binding behavior could sometimes be deliberate). > The long-term solution IMO is to get rid of words like S", i.e., have > only words with one semantics. For replacing these parsing words > recognizers may be the solution. That's indeed one possible solution. >>There are other problems in the gForth perspective, especially >>in that you can't write a full Forth text interpreter in the >>classical model. > > Incorrect and unsubstantiated claims...is your name Hugh Aguilar? Indeed, you can write a classical text interpretern in Gforth, the same way as in fig-Forth, VFX or whatever. The non-classical magic of Gforth's approach happens in FIND, the non-classical magic of VFX's approach happens in COMPILE,. >>The Forth >>202x technical committee should start by having a long >>discussion about what compilation in Forth actually involves. > > Fine with me, although somewhat sceptical given the way earlier > discussions have gone. The last discussion was pretty long ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-24 11:22 +0000 |
| Message-ID | <2015Apr24.132234@mips.complang.tuwien.ac.at> |
| In reply to | #38552 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> So you hang the two semantics of words like S" on one xt, the
>> interpretation semantics is performed by EXECUTE, the compilation
>> semantics by COMPILE,. That's a good idea for words with default
>> compilation semantics (i.e., normal words like +), but not for words
>> like S", because it breaks the relation between EXECUTE and COMPILE,
>> i.e., COMPILE, being equivalent to
>>
>> : compile, postpone literal postpone execute ;
>
>IIRC, the result of our last discussion was that this equivalence doesn't
>hold for compile-only words, because you aren't allowed to tick them. As
>you derive this equivalence from ' foo execute = interpretation semantics.
>If you can't tick foo in a standard way, ' foo execute = undefined; and that
>certainly beaks the compile, equivalence, too.
Sure, if you like languages with undefined behaviour, one can argue
that way.
OTOH, if you look at how COMPILE, is used, there are two ways to use
it:
1) Use it in text interpreters.
2) Use it to append the same semantics to a definition that EXECUTE
executes.
Both uses occur in programs that are out there, so we should implement
our systems such that they both work.
One may argue that not all xts tend to be used with use 2 (also with
use 1, BTW; consider xts coming from :NONAME words), so it's good
enough if these xts don't behave in a way compatible with use 2. In
particular, as I mentioned above, the (single) xt of S" in VFX does
not work properly with use 2.
One may consider that good enough as long as nobody uses it, so no
customer complains, but one should be aware that it is a good-enough
solution, not the right thing (and good-enough more in the Washington
(Redmond) style, not as in the New Jersey (Murray Hill) style that
Gabriel's paper compared the MIT approach to).
Anyway, just because no customer has complained to Stephen Pelc yet
does not mean that there is no code out there that uses COMPILE, in
use pattern 2, with an xt where VFX breaks the pattern. Nobody
complained to Stephen Pelc about VFX breaking return-address
manipulations until you came along.
>> This equivalence is used in, e.g., various OOF packages (dynamic
>> binding EXECUTEs, early binding COMPILE,s), but fortunately you don't
>> use the xt of S" etc. in that context, and ticking S" is rare in
>> general, so the problem does not occur in practice for now.
>
>And we have managed to make sure the problem can't occur in a standard
>program for the Forth-2012 standard. By making all those words that won't
>hold that equivalence untickable. As I'm fully for tightening up the spec,
>we can tighten it up differently.
Tightening it up in a way that would destandardize the existing uses
is a no-go.
I also don't see a good way to tighten it up in a way that would allow
VFXs current implementation.
>Usually, thise OOF package use :NONAME xts for method implementations, and
>:NONAME-xts work. People who use SET-COMPILER on their xts create non-
>standard programs, and they probably know what they do (different early/late
>binding behavior could sometimes be deliberate).
Deliberate mistakes, like STATE-smart words. Looks cute at first, and
the problems are only seen far later, perhaps by someone else.
So it seems that you suggest that SET-COMPILER and the like will never
be standardized. Fine with me.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-24 11:18 -0700 |
| Message-ID | <8073a6d0-8f22-487c-ad0a-0db91a50e567@googlegroups.com> |
| In reply to | #38559 |
On Friday, April 24, 2015 at 5:17:04 AM UTC-7, Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: > >Anton Ertl wrote: > > > >> So you hang the two semantics of words like S" on one xt, the > >> interpretation semantics is performed by EXECUTE, the compilation > >> semantics by COMPILE,. That's a good idea for words with default > >> compilation semantics (i.e., normal words like +), but not for words > >> like S", because it breaks the relation between EXECUTE and COMPILE, > >> i.e., COMPILE, being equivalent to > >> > >> : compile, postpone literal postpone execute ; > > > >IIRC, the result of our last discussion was that this equivalence doesn't > >hold for compile-only words, because you aren't allowed to tick them. As > >you derive this equivalence from ' foo execute = interpretation semantics. > >If you can't tick foo in a standard way, ' foo execute = undefined; and that > >certainly beaks the compile, equivalence, too. > > Sure, if you like languages with undefined behaviour, one can argue > that way. > > OTOH, if you look at how COMPILE, is used, there are two ways to use > it: > > 1) Use it in text interpreters. > > 2) Use it to append the same semantics to a definition that EXECUTE > executes. > > Both uses occur in programs that are out there, so we should implement > our systems such that they both work. > > One may argue that not all xts tend to be used with use 2 (also with > use 1, BTW; consider xts coming from :NONAME words), so it's good > enough if these xts don't behave in a way compatible with use 2. In > particular, as I mentioned above, the (single) xt of S" in VFX does > not work properly with use 2. > > One may consider that good enough as long as nobody uses it, so no > customer complains, but one should be aware that it is a good-enough > solution, not the right thing (and good-enough more in the Washington > (Redmond) style, not as in the New Jersey (Murray Hill) style that > Gabriel's paper compared the MIT approach to). > > Anyway, just because no customer has complained to Stephen Pelc yet > does not mean that there is no code out there that uses COMPILE, in > use pattern 2, with an xt where VFX breaks the pattern. Nobody > complained to Stephen Pelc about VFX breaking return-address > manipulations until you came along. > > >> This equivalence is used in, e.g., various OOF packages (dynamic > >> binding EXECUTEs, early binding COMPILE,s), but fortunately you don't > >> use the xt of S" etc. in that context, and ticking S" is rare in > >> general, so the problem does not occur in practice for now. > > > >And we have managed to make sure the problem can't occur in a standard > >program for the Forth-2012 standard. By making all those words that won't > >hold that equivalence untickable. As I'm fully for tightening up the spec, > >we can tighten it up differently. > > Tightening it up in a way that would destandardize the existing uses > is a no-go. You two, with your talk about "untickable words," are purposely obfuscating Forth. You are trying to baffle the Forth users (you had me pretty well baffled starting in 2009 and continuing until just now in this thread when I figured out the solution). The ANS-Forth document has a section (4.1.2) with the ominous heading: "Ambiguous Conditions." One of the many ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." In gForth this was interpreted to mean that it is ANS-Forth legal for FIND and tick to abort when given a word for which: "Interpretation semantics for this word are undefined." I think that this was done for the purpose of preventing the user from writing an outer-interpreter, and this was done for the purpose of preventing the user from writing a cross-compiler. > I also don't see a good way to tighten it up in a way that would allow > VFXs current implementation. You are playing dumb in order to make the readers believe that it is legal in ANS-Forth for FIND and tick to abort for certain words (gForth) or for certain words to have an xt (execution token) that can't be executed (VFX), and you are doing this for the purpose of making the readers believe that they can't write a cross-compiler in ANS-Forth. I already gave you the solution (works for both VFX and gForth, despite the fact that these compilers are incompatible): : +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate : ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate : ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate : >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate : abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate : begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate : do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate : does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate : else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate : exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate : I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate : leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate : literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate : loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate : r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate : r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate : recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate : repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate : s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate : then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate : unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate : until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate : while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate : [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate : ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate : [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate : 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate : 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate : 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate : ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate : again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate : c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate : case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate : compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate : endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate : endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate : of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate : [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate : 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate : fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate : (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate : locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate : ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate : ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate : cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate : cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate : sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate
[toc] | [prev] | [next] | [standalone]
Page 13 of 17 — ← Prev page 1 … 11 12 [13] 14 15 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web