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 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-18 23:58 -0700 |
| Message-ID | <cfad31de-3a3c-4e95-91ec-9913de579fcf@googlegroups.com> |
| In reply to | #39840 |
> > If you take out all ambiguities what does remain? How much of it? I > > said there are TOO MANY ambiguities. > > Section "4.1.2 Ambiguous conditions" covers them all. Which ones would > you make unambiguous? > TOO MANY. I don't have the time here to fix the standard. I also don't trust you that you really want this answer from me. I also don't believe that anybody that could really have the power to modify the standard will ever listen to me. Stephen Pelc said that clearly. > > > > >> > > >> >> Personally I think that ANS was born just to be an umbrella for some forths > >> >> at that time. > >> >> Those forths had a lot of incompatibilities so the ANS was forced > >> >> to "accomodate" these incompatibilities as "ambiguous conditions". > >> > > >> > I agree. And we're still living with the effects. > >> > > >> > >> As someone that does standards for a living (elsewhere, not here) I'm > >> fascinated by the assertion that a standard that doesn't require specific > >> effects on all inputs is considered in some way flawed. If there's one > > > > It was about FIND (or tick). There are not too many inputs. In fact > > there is only one input: the word. Do you find it? Or don't you? The > > word type or how many types can we have, it's another discussion. > > Let's have that discussion. > > We have positive integers, unsigned numbers, negative numbers, zero and > so on. There are limits to numbers; varying cells sizes make max and mins > vary from system to system. 123456789 123456789 * is a valid number, but > it is far too large for my system to represent accurately. Numbers have > ambiguities. > > The same is true of words. There are groups of words, and one of them -- > those with no interpretation semantics -- results in an ambiguous > condition and it's up to each system what to do. > Still one input: word or not a word? Numbers are not words. Return "not found" for numbers. Words are words. If you found it, return its xt. Full stop. It's not the function of tick to check if the words can be executed or not in interpretation mode or any other mode. Tick should find something and return an xt, EXECUTE is for executing. > > > >> thing that standards folks try not to do, it's bind the hands of > >> implementors or disqualify systems by being over prescriptive. We also > >> try to ensure that users (those the implementors wish to sell to) can > >> take what they have, and with little or no changes, use our systems. > >> > >> An example of that is Hugh's insistence that the control flow stack > >> should be a separate stack. It's explicitly mentioned in the standard > >> that the control flow stack might be the data stack. Generations of Forth > >> programmers have managed to write portable Forth with this ambiguity. > >> Systems can choose to implement the control flow stack in a multiplicity > >> of ways. > >> > > The control stack being data stack is really obsolete. It's so simple > > to have a separate stack for control flow, even for the most > > constrained embedded systems! I would see this another way: starting > > with '90 (for example) the modern forth systems should have been > > trying to insists on separate control flow stack. Now we would have > > been able to call this an obsolete feature and take away another "may > > or may not" from the 20xy standard. > > At compile time we would require 3 stacks. Why is this needed? > Asking again and again questions which was responded a lot of times before don't help a discussion. You probably don't need 3 stacks. A good standard will force you to implement 3 stacks. If you feel this too hard, give away being standard. Standards are not for everybody. > > > >> Yes, sometimes a standard gets it wrong. Then it's up to the standards > >> group *to accomodate existing practise* where possible, and without > >> requiring major re-engineering work. But there has to be evidence that > >> there is a problem caused by the lack of (or incorrect) specification. > >> > >> Why would you want it otherwise? > > > > I would want it said clearly in the next standard (that tick find etc > > to return an xt) and the "major forth vendors" (including open source > > ones) to fix their implementation. Is this requiring major > > re-engineering work? I don't think so. > > > > What would you do with this conformity? In particular, what would you > have ' IF do when executed? > Are you going to ask this kind of question to any programmer trying to use a word? It's about ' (tick). I want it to give me the xt of the word not to abort in my face. Simple as that. It's my problem what I do with the word ticked. > >
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-19 08:23 +0100 |
| Message-ID | <mm0fv1$vt3$1@dont-email.me> |
| In reply to | #39848 |
on 19/06/2015 07:58:39, Raimond Dragomir wrote: >> > If you take out all ambiguities what does remain? How much of it? I >> > said there are TOO MANY ambiguities. >> >> Section "4.1.2 Ambiguous conditions" covers them all. Which ones would >> you make unambiguous? >> > TOO MANY. I don't have the time here to fix the standard. I also don't > trust you that you really want this answer from me. I also don't > believe that anybody that could really have the power to modify the > standard will ever listen to me. Stephen Pelc said that clearly. > In other words, you want to shout and yell and jump up and down but not do anything because no-one ever listens to you. >> >> > >> >> > >> >> >> Personally I think that ANS was born just to be an umbrella for some forths >> >> >> at that time. >> >> >> Those forths had a lot of incompatibilities so the ANS was forced >> >> >> to "accomodate" these incompatibilities as "ambiguous conditions". >> >> > >> >> > I agree. And we're still living with the effects. >> >> > >> >> >> >> As someone that does standards for a living (elsewhere, not here) I'm >> >> fascinated by the assertion that a standard that doesn't require specific >> >> effects on all inputs is considered in some way flawed. If there's one >> > >> > It was about FIND (or tick). There are not too many inputs. In fact >> > there is only one input: the word. Do you find it? Or don't you? The >> > word type or how many types can we have, it's another discussion. >> >> Let's have that discussion. >> >> We have positive integers, unsigned numbers, negative numbers, zero and >> so on. There are limits to numbers; varying cells sizes make max and mins >> vary from system to system. 123456789 123456789 * is a valid number, but >> it is far too large for my system to represent accurately. Numbers have >> ambiguities. >> >> The same is true of words. There are groups of words, and one of them -- >> those with no interpretation semantics -- results in an ambiguous >> condition and it's up to each system what to do. >> > Still one input: word or not a word? Numbers are not words. Return > "not found" for numbers. Words are words. If you found it, return its > xt. Full stop. It's not the function of tick to check if the words can > be executed or not in interpretation mode or any other mode. Tick > should find something and return an xt, EXECUTE is for executing. I'll repeat my question. What should the xt that ' IF returns do? > >> > >> >> thing that standards folks try not to do, it's bind the hands of >> >> implementors or disqualify systems by being over prescriptive. We also >> >> try to ensure that users (those the implementors wish to sell to) can >> >> take what they have, and with little or no changes, use our systems. >> >> >> >> An example of that is Hugh's insistence that the control flow stack >> >> should be a separate stack. It's explicitly mentioned in the standard >> >> that the control flow stack might be the data stack. Generations of Forth >> >> programmers have managed to write portable Forth with this ambiguity. >> >> Systems can choose to implement the control flow stack in a multiplicity >> >> of ways. >> >> >> > The control stack being data stack is really obsolete. It's so simple >> > to have a separate stack for control flow, even for the most >> > constrained embedded systems! I would see this another way: starting >> > with '90 (for example) the modern forth systems should have been >> > trying to insists on separate control flow stack. Now we would have >> > been able to call this an obsolete feature and take away another "may >> > or may not" from the 20xy standard. >> >> At compile time we would require 3 stacks. Why is this needed? >> > Asking again and again questions which was responded a lot of times > before don't help a discussion. I'm asking you, not other people who have thought about it and responded elsewhere. > You probably don't need 3 stacks. A good standard will force you to > implement 3 stacks. If you feel this too hard, give away being > standard. Standards are not for everybody. That's almost funny. > >> > >> >> Yes, sometimes a standard gets it wrong. Then it's up to the standards >> >> group *to accomodate existing practise* where possible, and without >> >> requiring major re-engineering work. But there has to be evidence that >> >> there is a problem caused by the lack of (or incorrect) specification. >> >> >> >> Why would you want it otherwise? >> > >> > I would want it said clearly in the next standard (that tick find etc >> > to return an xt) and the "major forth vendors" (including open source >> > ones) to fix their implementation. Is this requiring major >> > re-engineering work? I don't think so. >> > >> >> What would you do with this conformity? In particular, what would you >> have ' IF do when executed? >> > Are you going to ask this kind of question to any programmer trying to > use a word? It's about ' (tick). I want it to give me the xt of the > word not to abort in my face. Simple as that. It's my problem what I > do with the word ticked. > There are two things you can do wih an xt. COMPILE, it or EXECUTE it. What would you have ' IF COMPILE, do when executed, or ' IF EXECUTE do?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-19 01:01 -0700 |
| Message-ID | <c588e444-6e45-48d6-883c-f0076f5560ee@googlegroups.com> |
| In reply to | #39850 |
On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: > > I'll repeat my question. What should the xt that ' IF returns do? > It shouldn't do anything, Alex; it's an XT, a token that represents some executable code. I'm being slightly facetious, but only slightly. The point is, ' doesn't know what I want to do with that XT. How dare it presume that I want to execute it, and that executing it in a particular state is illegal. Perhaps I don't want to execute it at all. Perhaps I want to do this, as I can in my system: ' IF >LINK 10 DUMP Allowing me to see the dictionary entry, it's linkage info, flags etc.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Östreicher <thomas.oestreicher@gmail.com> |
|---|---|
| Date | 2015-06-19 01:07 -0700 |
| Message-ID | <04d4c360-d274-41a0-8b75-9e8394945599@googlegroups.com> |
| In reply to | #39856 |
On Friday, 19 June 2015 10:01:26 UTC+2, Mark Wills wrote: > On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: > > > > I'll repeat my question. What should the xt that ' IF returns do? > > > It shouldn't do anything, Alex; it's an XT, a token that represents > some executable code. I'm being slightly facetious, but only slightly. > The point is, ' doesn't know what I want to do with that XT. How > dare it presume that I want to execute it, and that executing it > in a particular state is illegal. Perhaps I don't want to execute > it at all. Perhaps I want to do this, as I can in my system: > > ' IF >LINK 10 DUMP > > Allowing me to see the dictionary entry, it's linkage info, flags etc. Maybe I am wrong here, but isn't this what name tokens in forth200x are for?
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-19 09:38 +0000 |
| Message-ID | <5583e243.67171534@news.eternal-september.org> |
| In reply to | #39856 |
On Fri, 19 Jun 2015 01:01:25 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: >On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: >> >> I'll repeat my question. What should the xt that ' IF returns do? >> >It shouldn't do anything, Alex; it's an XT, a token that represents >some executable code. I'm being slightly facetious, but only slightly. >The point is, ' doesn't know what I want to do with that XT. How >dare it presume that I want to execute it, and that executing it >in a particular state is illegal. Perhaps I don't want to execute >it at all. Perhaps I want to do this, as I can in my system: > >' IF >LINK 10 DUMP > >Allowing me to see the dictionary entry, it's linkage info, flags etc. An excellent example. In my opinion, a word with a name should have an xt. The xt is the token for access to all the other parts of the word, including those parts that the standard does not describe. That EXECUTE or COMPILE, give silly results when applied to a specific xt does not remove the utility of the xt for that word. 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-19 02:51 -0700 |
| Message-ID | <10c0e92d-cdfa-4cf9-bcf4-7e19785a09e1@googlegroups.com> |
| In reply to | #39860 |
On Friday, 19 June 2015 10:38:53 UTC+1, Stephen Pelc wrote: > On Fri, 19 Jun 2015 01:01:25 -0700 (PDT), Mark Wills > <markwills1970@gmail.com> wrote: > > >On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote: > >> > >> I'll repeat my question. What should the xt that ' IF returns do? > >> > >It shouldn't do anything, Alex; it's an XT, a token that represents > >some executable code. I'm being slightly facetious, but only slightly. > >The point is, ' doesn't know what I want to do with that XT. How > >dare it presume that I want to execute it, and that executing it > >in a particular state is illegal. Perhaps I don't want to execute > >it at all. Perhaps I want to do this, as I can in my system: > > > >' IF >LINK 10 DUMP > > > >Allowing me to see the dictionary entry, it's linkage info, flags etc. > > An excellent example. > > In my opinion, a word with a name should have an xt. The xt is > the token for access to all the other parts of the word, including > those parts that the standard does not describe. That EXECUTE or > COMPILE, give silly results when applied to a specific xt does > not remove the utility of the xt for that word. > > Stephen Agree.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-20 16:35 +0000 |
| Message-ID | <2015Jun20.183512@mips.complang.tuwien.ac.at> |
| In reply to | #39860 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Fri, 19 Jun 2015 01:01:25 -0700 (PDT), Mark Wills
><markwills1970@gmail.com> wrote:
>>Perhaps I want to do this, as I can in my system:
>>
>>' IF >LINK 10 DUMP
>>
>>Allowing me to see the dictionary entry, it's linkage info, flags etc.
>
>An excellent example.
>
>In my opinion, a word with a name should have an xt.
Or maybe two, as described in the standard for the result of FIND.
>The xt is
>the token for access to all the other parts of the word, including
>those parts that the standard does not describe.
Somehow I find it strange that you have claimed in earlier times that
the non-standardization of words like >LINK was a great achievement of
Forth-94 (and interpret a one-token-to-rule-them-all role for the xt
into that), and now you applaud Mark Will's use of >LINK. Have you
changed your position, or is this an exercise in doublethink?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-20 21:28 -0700 |
| Message-ID | <9b41f6ee-1871-48b7-bc9a-1778c42deccb@googlegroups.com> |
| In reply to | #39894 |
A nice attempt to swerve the argument away from tick. You know very well Stephen was referring to tick, not >LINK. ' is the only way to get access to the word in interpretation mode. Who cares if it has "interpretation semantics" or not? Maybe I don't want to interpret it. My example using DUMP is an example of that. If I'm correct, Gforth can't do that. And that is pathetic.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-20 21:33 -0700 |
| Message-ID | <9e152f45-1e18-41f1-9f23-cbcd352eda8a@googlegroups.com> |
| In reply to | #39914 |
On Saturday, June 20, 2015 at 9:28:22 PM UTC-7, Mark Wills wrote: > A nice attempt to swerve the argument away from tick. You know very well Stephen was referring to tick, not >LINK. > > ' is the only way to get access to the word in interpretation mode. Who cares if it has "interpretation semantics" or not? Maybe I don't want to interpret it. My example using DUMP is an example of that. If I'm correct, Gforth can't do that. And that is pathetic. Which post are you responding to?
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-20 21:49 -0700 |
| Message-ID | <6d30b58f-ccbb-4cf7-bd5d-169542833f36@googlegroups.com> |
| In reply to | #39915 |
Sorry. I was responding to Anton's last post. It seems Gmail via mobile phone doesn't quote the posts.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-21 14:01 +0000 |
| Message-ID | <2015Jun21.160132@mips.complang.tuwien.ac.at> |
| In reply to | #39914 |
Mark Wills <markwills1970@gmail.com> writes:
>A nice attempt to swerve the argument away from tick. You know very well St=
>ephen was referring to tick, not >LINK.
No, he called your example, including ">LINK", excellent. And he
explicitly wrote about "access to other parts of the word".
>' is the only way to get access to the word in interpretation mode.
:noname c" if" ; execute find drop
Also an ambiguous condition, i.e., also non-standard; and the
following are non-standard from using non-standard words:
s" if" find-name name>int
comp' if drop
The latter produces an xt for the compilation semantics of IF, which
is more likely what the user wanted to get.
> Who car=
>es if it has "interpretation semantics" or not? Maybe I don't want to inter=
>pret it.
Why use "'", if you don't want interpretation semantics?
>My example using DUMP is an example of that. If I'm correct, Gfort=
>h can't do that.
In Gforth 0.7:
:noname c" if" ; execute find drop >name 32 dump
7FFFF69F4AD8: 70 4A 9F F6 FF 7F 00 00 - 12 00 00 00 00 00 00 80 pJ..............
7FFFF69F4AE8: 63 6F 6D 70 69 6C 65 2D - 6F 6E 6C 79 2D 65 72 72 compile-only-err
ok
s" if" find-name 32 dump
7FFFF6A01F00: 90 1E A0 F6 FF 7F 00 00 - 02 00 00 00 00 00 00 E0 ................
7FFFF6A01F10: 49 46 20 20 20 20 20 20 - E5 43 40 00 00 00 00 00 IF .C@.....
ok
comp' if drop >name 32 dump
7FFFF6A01F00: 90 1E A0 F6 FF 7F 00 00 - 02 00 00 00 00 00 00 E0 ................
7FFFF6A01F10: 49 46 20 20 20 20 20 20 - E5 43 40 00 00 00 00 00 IF .C@.....
ok
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-21 14:19 +0000 |
| Message-ID | <5586c4e9.256267662@news.eternal-september.org> |
| In reply to | #39894 |
On Sat, 20 Jun 2015 16:35:12 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>In my opinion, a word with a name should have an xt. > >Or maybe two, as described in the standard for the result of FIND. No. The concession to cmForth in ANS can now be seen as a mistake. An xt is (or should be) the token from which all else about a word can be derived. A further lesson is that there may still be other mistakes in the standard. It is more productive to assume that there are mistakes in the standard and to be prepared to change them over time. >>The xt is >>the token for access to all the other parts of the word, including >>those parts that the standard does not describe. > >Somehow I find it strange that you have claimed in earlier times that >the non-standardization of words like >LINK was a great achievement of >Forth-94 (and interpret a one-token-to-rule-them-all role for the xt >into that), and now you applaud Mark Will's use of >LINK. Have you >changed your position, or is this an exercise in doublethink? I applauded his example, not a specific word in that example. No change of position, no doublethink. Just a recognition that parts of a Forth system may not be portable. Just consider the word >LINK again. What's at that address? We have seen both absolute and relative links in the past. It is not sensible for a standard to define the implementation. If a system chooses to expose >LINK that's its business, but the standard has no business mandating or preferring one dictionary implementation over another. There's actually nothing wrong with having to write some code that is implementation dependent. The issue is in the documentation and specification of it. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-22 13:16 +0000 |
| Message-ID | <2015Jun22.151615@mips.complang.tuwien.ac.at> |
| In reply to | #39929 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 20 Jun 2015 16:35:12 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>In my opinion, a word with a name should have an xt.
>>
>>Or maybe two, as described in the standard for the result of FIND.
>
>No. The concession to cmForth in ANS can now be seen as a mistake.
>An xt is (or should be) the token from which all else about a word
>can be derived.
No. As long as we have words with non-default and non-immediate
compilation semantics (such as S" and TO), the way to go is to
1) have xt0, an xt representing the interpretation semantics
2) have a compilation token representing the compilation semantics,
consisting of xt1 xt2, where xt1 is xt0 for normal and immediate
words, and some other xt for S"-like words; and xt2 is the xt of
EXECUTE or COMPILE,.
Deriving everything else from the xt0 and xt1 is not a problem of
principle but one of implementation cost and usefulness. Sure it is
possible to implement things in a way that allows us to, e.g., get all
the nts of named words that have the passed xt as xt0, or as xt1, but
will any system implementor do it?
>A further lesson is that there may still be other mistakes in the
>standard. It is more productive to assume that there are mistakes
>in the standard and to be prepared to change them over time.
I think the major mistake in this area is words like S". We should
get rid of them.
>Just a recognition that parts
>of a Forth system may not be portable. Just consider the word >LINK
>again. What's at that address? We have seen both absolute and relative
>links in the past. It is not sensible for a standard to define the
>implementation. If a system chooses to expose >LINK that's its
>business, but the standard has no business mandating or preferring one
>dictionary implementation over another.
Like one where all else about a word can be derived from the xt?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-22 16:53 +0000 |
| Message-ID | <55883c10.352306620@news.eternal-september.org> |
| In reply to | #39962 |
On Mon, 22 Jun 2015 13:16:15 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>No. The concession to cmForth in ANS can now be seen as a mistake. >>An xt is (or should be) the token from which all else about a word >>can be derived. > >No. As long as we have words with non-default and non-immediate >compilation semantics (such as S" and TO), the way to go is to > >1) have xt0, an xt representing the interpretation semantics > >2) have a compilation token representing the compilation semantics, >consisting of xt1 xt2, where xt1 is xt0 for normal and immediate >words, and some other xt for S"-like words; and xt2 is the xt of >EXECUTE or COMPILE,. > >Deriving everything else from the xt0 and xt1 is not a problem of >principle but one of implementation cost and usefulness. Sure it is >possible to implement things in a way that allows us to, e.g., get all >the nts of named words that have the passed xt as xt0, or as xt1, but >will any system implementor do it? Now you have exposed xt0, xt1, xt2 and we need an nt too! These are tokens from one implementation, not from common practice. All this is "stuff" that an xt was designed to avoid. If you want to rename xt to wt (word token), be my guest. Your four tokens are part of the implementation. They can all be obtained from the xt/wt. >I think the major mistake in this area is words like S". We should >get rid of them. We're lumbered with them for the next twenty years or so. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-23 15:39 +0000 |
| Message-ID | <2015Jun23.173949@mips.complang.tuwien.ac.at> |
| In reply to | #39969 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Mon, 22 Jun 2015 13:16:15 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>No. The concession to cmForth in ANS can now be seen as a mistake.
>>>An xt is (or should be) the token from which all else about a word
>>>can be derived.
>>
>>No. As long as we have words with non-default and non-immediate
>>compilation semantics (such as S" and TO), the way to go is to
>>
>>1) have xt0, an xt representing the interpretation semantics
>>
>>2) have a compilation token representing the compilation semantics,
>>consisting of xt1 xt2, where xt1 is xt0 for normal and immediate
>>words, and some other xt for S"-like words; and xt2 is the xt of
>>EXECUTE or COMPILE,.
>>
>>Deriving everything else from the xt0 and xt1 is not a problem of
>>principle but one of implementation cost and usefulness. Sure it is
>>possible to implement things in a way that allows us to, e.g., get all
>>the nts of named words that have the passed xt as xt0, or as xt1, but
>>will any system implementor do it?
>
>Now you have exposed xt0, xt1, xt2 and we need an nt too! These are
>tokens from one implementation, not from common practice.
They are even standardized:
FIND arguably returns xt0 in interpret state and xt1 in compile state,
and it returns a flag that corresponds to xt2 (when the flag is -1,
xt2 is the xt of COMPILE, and when the flag is 1, xt2 is the xt of
EXECUTE).
NAME>INTERPRET returns xt0
NAME>COMPILE returns xt1 xt2
In many systems xt0=xt1, but if you want to be able to tick S" and TO
(which is not guaranteed by the standard, but which you advocate) and
if the resulting execution token should behave as standard execution
tokens behave, then for these words xt0 must be different from xt1.
>All this is "stuff" that an xt was designed to avoid. If you want to
>rename xt to wt (word token), be my guest. Your four tokens are part
>of the implementation. They can all be obtained from the xt/wt.
I don't care about the name of the token; what I do care about is that
COMPILE, works properly.
Concerning whether xt0 (or xt1) also serves as nt or, in general as
the key to all the stuff concerning the word, that's fine with me, but
I expect that some implementors won't like this requirement. It
restricts system implementations, and I don't see a significant
advantage to programmers. But if you convince the other system
implementors, I certainly won't object.
>>I think the major mistake in this area is words like S". We should
>>get rid of them.
>
>We're lumbered with them for the next twenty years or so.
Sure it will take a long time to get rid of them completely, but we
could start by putting the replacement in place and declaring them to
be obsolescent in the near future, and then they will play the same
role that, say, SPAN has played in the last 20 years.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-23 18:11 +0000 |
| Message-ID | <55899e7b.443037660@news.eternal-september.org> |
| In reply to | #39994 |
On Tue, 23 Jun 2015 15:39:49 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >>Now you have exposed xt0, xt1, xt2 and we need an nt too! These are >>tokens from one implementation, not from common practice. > >They are even standardized: Standardised in 2012 perhaps, but we were wrong! Before we go ahead with further mission creep, we should actually define what we are trying to achieve in the kernel. For example, maintenance of conceptual simplicity is one objective that I favour. If we cannot work out how to live with a single xt, then we need to go back to the drawing board. We also need to preserve the classical Forth interpreter loop (after deciding about IMMEDIATE). I should have followed my instinct and voted no to a number of late proposals for Forth 2012. >In many systems xt0=xt1, but if you want to be able to tick S" and TO >(which is not guaranteed by the standard, but which you advocate) and >if the resulting execution token should behave as standard execution >tokens behave, then for these words xt0 must be different from xt1. I have never said that the xts returned by ticking S" or TO should be useful for much, only that they must exist. Once we have a set of objectives and a roadmap to these objectives, then we can decide where our targets lie. >Sure it will take a long time to get rid of them completely, but we >could start by putting the replacement in place and declaring them to >be obsolescent in the near future, and then they will play the same >role that, say, SPAN has played in the last 20 years. There is (IMHO) no replacement for S" in common use. If *you* want to get rid of S" then *you* have to say why and make proposals. Just saying that visible objectors are wrong is inadequate for these purposes. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-20 16:26 +0000 |
| Message-ID | <2015Jun20.182607@mips.complang.tuwien.ac.at> |
| In reply to | #39856 |
Mark Wills <markwills1970@gmail.com> writes:
>On Friday, 19 June 2015 08:23:30 UTC+1, Alex McDonald wrote:
>The point is, ' doesn't know what I want to do with that XT. How
>dare it presume that I want to execute it, and that executing it
>in a particular state is illegal.
Ticking IF is non-standard. You cannot get an xt of IF with '.
Whether you want to execute it is irrelevant, and state is also
irrelevant. If you get an xt for the compilation semantics of IF in
Gforth, you can EXECUTE it, and STATE does not matter:
: foo [ comp' if drop execute ] ." hello" then ;
true foo \ prints "hello"
false foo \ prints nothing
SEE FOO shows:
: foo
IF .\" hello"
THEN ; ok
> Perhaps I don't want to execute
>it at all. Perhaps I want to do this, as I can in my system:
>
>' IF >LINK 10 DUMP
So this code is specific for your system anyway. In what way would
standardizing "' IF" help?
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-20 21:55 -0700 |
| Message-ID | <b054e81e-fff0-438c-b487-73b490925edd@googlegroups.com> |
| In reply to | #39892 |
On Saturday, June 20, 2015 at 9:34:56 AM UTC-7, Anton Ertl wrote: > Ticking IF is non-standard. You cannot get an xt of IF with '. > Whether you want to execute it is irrelevant, and state is also > irrelevant. My disambiguifiers refute Anton Ertl's assertion that ticking IF is non-standard. It is in fact possible to get an xt of IF with ' that can be given to EXECUTE (when STATE is set, otherwise you get an error-message) and that can be given to COMPILE, (presumably when meta-compiling an immediate word). Here the bug is fixed by a disambiguifier: : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : my-if [ ' if ] literal execute ; immediate : ttt ( flag -- ) my-if ." true" else ." false" then ; 1 ttt true 0 ttt false Note that executing IF in interpretation mode results in IF aborting with an error-message: if *** no interpretation semantics for: IF *** -> if IF should abort in the programmer's face when it is used in interpretation mode --- the programmer has a bug and needs to be told. IF should not abort when used in compilation mode (inside of the TTT definition) --- this is, in fact, the context in which IF is supposed to be executed. This thread has run for over 200 posts now, and Anton Ertl has yet to say: "Thanks for explaining to me how it is possible to tick IF in standard ANS-Forth to obtain a valid xt. I'll put your disambiguifiers in my next gForth release." I've previously said that I feel like Sisyphus pushing the stone up the hill, only to have it roll back down again --- I have told you guys about the disambiguifiers dozens of times now, but you just continue playing dumb as if you just don't understand --- you are obviously hoping that I will eventually give up, and you will never have to face up to the fact that ANS-Forth was sabotaged to prevent the users from writing custom outer-interpreters. Once again, here is the sabotage: (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." Is there any way that I could make this more clear? If people can't see this, then that is purposeful blindness --- it is as clear as clear can be!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-06-21 14:26 +0000 |
| Message-ID | <2015Jun21.162640@mips.complang.tuwien.ac.at> |
| In reply to | #39918 |
hughaguilar96@gmail.com writes:
>On Saturday, June 20, 2015 at 9:34:56 AM UTC-7, Anton Ertl wrote:
>> Ticking IF is non-standard. You cannot get an xt of IF with '.
>> Whether you want to execute it is irrelevant, and state is also
>> irrelevant. =20
>
>My disambiguifiers refute Anton Ertl's assertion that ticking IF is non-sta=
>ndard. It is in fact possible to get an xt of IF with ' that can be given t=
>o EXECUTE (when STATE is set, otherwise you get an error-message) and that =
>can be given to COMPILE, (presumably when meta-compiling an immediate word)=
>.
>
>Here the bug is fixed by a disambiguifier:=20
>
>: if state @ 0=3D abort" *** no interpretation semantics for: IF ***" pos=
>tpone if ; immediate=20
Ouch. A state-smart IF. Better read
<http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>.
A better implementation is:
: if postpone if ; immediate
This IF is not compile-only in any way, but that's certainly better
than a state-smart IF.
>Note that executing IF in interpretation mode results in IF aborting with a=
>n error-message:=20
>
>if *** no interpretation semantics for: IF ***=20
> -> if=20
>
>IF should abort in the programmer's face when it is used in interpretation =
>mode --- the programmer has a bug and needs to be told.=20
Performing the compilation semantics of IF in interpretation state is
not a bug. Typical example
: foo [ 5 gen-some-code 6 gen-more-code ] ;
where gen-some-code contains POSTPONE 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-22 00:29 +0100 |
| Message-ID | <mm7h9c$pl1$1@dont-email.me> |
| In reply to | #39933 |
on 21/06/2015 15:26:38, wrote: >>My disambiguifiers refute Anton Ertl's assertion that ticking IF is non-sta= >>ndard. It is in fact possible to get an xt of IF with ' that can be given t= >>o EXECUTE (when STATE is set, otherwise you get an error-message) and that = >>can be given to COMPILE, (presumably when meta-compiling an immediate word)= >>. >> >>Here the bug is fixed by a disambiguifier:=20 >> >>: if state @ 0=3D abort" *** no interpretation semantics for: IF ***" pos= >>tpone if ; immediate=20 > > Ouch. A state-smart IF. Better read > <http://www.complang.tuwien.ac.at/papers/ertl98.ps.gz>. > > A better implementation is: > >: if postpone if ; immediate > > This IF is not compile-only in any way, but that's certainly better > than a state-smart IF. Hugh claims not read other people's work. He was already advised by me to read your paper and use an immediate POSTPONE IF on 3 April; https://groups.google.com/forum/#! original/comp.lang.forth/oXXQAGDKP7w/JTzQ5b9luQ4J
[toc] | [prev] | [next] | [standalone]
Page 5 of 17 — ← Prev page 1 … 3 4 [5] 6 7 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web