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 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-05 21:58 -0700 |
| Message-ID | <4b38721d-0b50-43de-97bc-29b423c8350a@googlegroups.com> |
| In reply to | #37988 |
On Sunday, April 5, 2015 at 9:53:52 PM UTC-7, WJ wrote: > hughaguilar96@gmail.com wrote: > > > Why this bothers me is that IF seems to have some kind of exulted status > > I believe that the word that you want is "exalted". Okay, you got me there.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-06 13:56 +0000 |
| Message-ID | <2015Apr6.155654@mips.complang.tuwien.ac.at> |
| In reply to | #37982 |
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 immedia=
>cy 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.
>Why this bothers me is that IF seems to have some kind of exulted status th=
>at ordinary immediate words lack.
Yes, Forth-94 and Forth-2012 do not give the programmer a way to
define a word without interpretation semantics (such as Gforth's
COMPILE-ONLY). That's not a big problem for programmers, and it
allows Forth implementations that don't support removing
interpretation semantics.
A bigger issue is that these standards do not give programmers a good
way to define words with unconventional combinations of interpretation
and compilation semantics, such as S". There have been some
discussions about adding such support, but that would require changes
deep inside some Forth systems, so it might be hard to get consensus
on. Also, I think that parsing words such as S" are the wrong
approach, so making such word user-definable leads the programmers
down the wrong path.
>Typically, in the header is a flags cell =
>that has various flags ("smudged," "immediate," etc.) that indicate attribu=
>tes of the word --- is there an "exulted" flag that I don't know about?
Gforth (up to 0.7) has a compile-only flag. The current development
version has a completely new header structure, not sure if we still
have the compile-only flag.
>Lets try an experiment:
>: if postpone if ; immediate \ meet the new IF same as the old IF
>IF is redefined ok
>: my-if [ ' if ] literal execute ; immediate ok
>: ttt my-if ." true" else ." false" then ; ok
>1 ttt true ok
>0 ttt false ok
>see my-if=20
>MY-IF (is IMMEDIATE)=20
>( 004C7AB0 E8CBFFFFFF ) CALL 004C7A80 IF
>( 004C7AB5 C3 ) NEXT,
>( 6 bytes, 2 instructions )
> ok
>
>Now we have a new version of IF that is immediate and does the same thing t=
>hat the old version of IF does, but which lacks the exulted status of IF of=
> being a part of ANS-Forth syntax. So, tell me Mr. Chairman, if the new IF =
>is effectively the same as the old IF, then what exactly was the purpose of=
> the old IF having exulted status of being a part of ANS-Forth syntax? What=
> not just flush this exulted-status idea altogether, as it isn't doing anyt=
>hing for us?
We have not received an RfD for adding interpretation semantics to IF.
If you think that that would be beneficial, go ahead and make one.
However, I see benefits of the unspecified interpretation semantics of
IF: On a number of Forth systems you get an error message instead of
silently compiling some code if you use IF interpretively. There are
also Forth systems that implement an interpretation semantics for IF
that skip the stuff between IF and ELSE/THEN if the flag is 0.
>Can you give me a list of all the words in ANS-Forth that have the exulted =
>status of being a part of ANS-Forth syntax?
You can search for "Interpretation semantics for this word are
undefined." yourself.
- 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-06 22:22 +0200 |
| Message-ID | <mfupsm$5sl$1@dont-email.me> |
| In reply to | #38009 |
Anton Ertl wrote: > Gforth (up to 0.7) has a compile-only flag. The current development > version has a completely new header structure, not sure if we still > have the compile-only flag. We still have, and it's still a flag. Otherwise, it would break too much code. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-06 18:09 -0700 |
| Message-ID | <590aeec0-6a37-451b-927c-c740bf2bc94c@googlegroups.com> |
| In reply to | #38009 |
On Monday, April 6, 2015 at 7:29:48 AM UTC-7, Anton Ertl 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 immedia= > >cy 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. In the good old days, words were either immediate or non-immediate. It seems hugely confusing to have IF not be immediate but not have defined interpretation semantics. What??? In my cross-compiler, I had three kinds of words: 1.) SYSTEM --- These execute on the host and access host memory. This is just the FORTH vocabulary --- it is extremely rare for anybody to write SYSTEM words. 2.) HOST --- These execute on the host and access the target memory image. 3.) TARG --- These execute on the target and access target memory. None of these are immediate. If you have a solid foundation like this, then you don't need any obscure lawyerly terminology about "semantics." Everything makes sense, is easy to explain, and is easy to error-check during compilation. > We have not received an RfD for adding interpretation semantics to IF. > If you think that that would be beneficial, go ahead and make one. Why would anybody want to use IF in interpretation mode (the outer interpreter or REPL)? > However, I see benefits of the unspecified interpretation semantics of > IF: On a number of Forth systems you get an error message instead of > silently compiling some code if you use IF interpretively. There are > also Forth systems that implement an interpretation semantics for IF > that skip the stuff between IF and ELSE/THEN if the flag is 0. Having unspecified semantics is a bad idea. The whole ANS-Forth document is full of words like "undefined" "implementation defined" "ambiguous" "may or may not" etc. None of this stuff makes any sense! If you don't want to go with a cross-compiler, and want to stick with a traditional Forth system, you can still simplify a lot by just having words be immediate or non-immediate like in Forth-83. I think that it should be an error to execute an immediate word in the outer-interpreter (STATE is zero). This is almost always a mistake. This error-checking is really all that you accomplished with your hokey scheme of making IF etc. have undefined interpretation semantics --- it is much easier to allow IF etc. to have valid xt values, but to just put some error-checking in the outer-interpreter so that it catches the common mistake of the user trying to execute an immediate word (the user should have used [IF] etc. rather than IF etc.). All of my words defined with MACRO: are immediate. It is difficult for me to remember whether a particular word was defined with : or with MACRO: --- sometimes the MACRO: words work in interpretive mode and sometimes not --- it would be more consistent if they either never worked or always worked. > >Can you give me a list of all the words in ANS-Forth that have the exulted = > >status of being a part of ANS-Forth syntax? > > You can search for "Interpretation semantics for this word are > undefined." yourself. Well, I did --- my SYNONYM is written. I still don't know why IF etc. are any different from immediate words. But, whatever --- I just work around these weird ANS-Forth issues...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-07 14:30 +0000 |
| Message-ID | <2015Apr7.163050@mips.complang.tuwien.ac.at> |
| In reply to | #38029 |
hughaguilar96@gmail.com writes:
>On Monday, April 6, 2015 at 7:29:48 AM UTC-7, Anton Ertl 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 imme=
>dia=3D
>> >cy is not the issue --- so what is the issue?
>>=20
>> The lack of defined interpretation semantics.
>>=20
>> BTW, the standard does not define IF to be immediate.
>
>In the good old days, words were either immediate or non-immediate. It seem=
>s hugely confusing to have IF not be immediate but not have defined interpr=
>etation semantics. What???
Forth-94 (and Forth-2012) have concepts that go beyond
single-xt-with-immediate-flag words. If you try to understand these
concepts by interpreting them in the terms of such implementations,
you will fail to get the concepts, and of course you will find that
confusing.
>> We have not received an RfD for adding interpretation semantics to IF.
>> If you think that that would be beneficial, go ahead and make one.
>
>Why would anybody want to use IF in interpretation mode (the outer interpre=
>ter or REPL)?=20
It was you who suggested that the lack of interpretation semantics for
IF (what you call "exulted") should be "flushed".
>Having unspecified semantics is a bad idea. The whole ANS-Forth document is=
> full of words like "undefined" "implementation defined" "ambiguous" "may o=
>r may not" etc. None of this stuff makes any sense!
Sure, every programmer would like the behaviour of his favourite Forth
system to be standardized. I think they may not be so keen on having
the behaviour of a different Forth system standardized, though,
because then their favourite system will probably change its behaviour
(at least in the long run) to be standard-compliant, and the programs
that the programmer has written would not run on the new version of
that Forth system.
>I think that it should be an error to execute an immediate word in the oute=
>r-interpreter (STATE is zero). This is almost always a mistake.
There are few immediate words defined in the standard, among them (
and \. For these it is not a mistake to use them in interpret state.
- 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-07 15:43 +0000 |
| Message-ID | <5523fb01.965588967@news.eternal-september.org> |
| In reply to | #38029 |
On Mon, 6 Apr 2015 18:09:39 -0700 (PDT), hughaguilar96@gmail.com wrote: >I think that it should be an error to execute an immediate word in the oute= >r-interpreter (STATE is zero). Why? >This is almost always a mistake. Why? Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-10 19:55 -0700 |
| Message-ID | <098cda39-95e5-4079-bceb-f5da300d81e5@googlegroups.com> |
| In reply to | #38045 |
On Tuesday, April 7, 2015 at 8:43:42 AM UTC-7, Stephen Pelc wrote: > On Mon, 6 Apr 2015 18:09:39 -0700 (PDT), hughaguilar96@gmail.com > wrote: > > >I think that it should be an error to execute an immediate word in the oute= > >r-interpreter (STATE is zero). > > Why? > > >This is almost always a mistake. > > Why? In the past, people tried having one state-smart word that worked in both interpretive mode and compilation mode. For example, CHAR could be used either way. This resulted in a lot of problems. One of the problems was that it was difficult to write a colon word that used the interpretive-version of the word. For example, if you want to write a colon word that pulls a character out of the input stream and does something with it, you couldn't do this easily (if you used CHAR in your definition, it would execute at compile-time rather than run-time). Now, we generally have two words. For example, CHAR is used in interpretive mode only and [CHAR] is used in compilation mode only. In "Thinking Forth" Charles Moore was quoted as saying: "Let the dictionary do the deciding." This means that you have different names for different words, rather than a single word that does different things conditionally depending upon some global state. The convention for naming is that the compilation-mode version of the word has square brackets around the name (note that IF and [IF] in ANS-Forth have the convention backwards). Anyway, I think that a word like IF should only work in compilation mode and not in interpretive mode. Apparently the ANS-Forth committee thought so too. Unfortunately, the ANS-Forth committee came up with this hokey scheme in which words like IF are documented to not have an interpretation semantics, and people like Anton Ertl (inspired by Loring Craymer, whoever the heck that is), have interpreted this to mean that the xt of these words either doesn't exist (FIND and ' abort rather than return an xt) or it does exist but aborts when executed (what VFX does). This is bizarre nonsense! The ANS-Forth document is full of terms like "undefined" and "ambiguous" and "implementation defined" and "may this or may that" etc. --- this is all pseudo-intellectual nonsense that sales-people who have never written a program will spew in an attempt to appear to be experts on the language --- the motto of sales-people the world over is: "If you can't dazzle them with brilliance, then baffle them with bull!" (I saw a t-shirt once that had this motto on it). If you want IF etc. to abort with an error message when used in interpretive mode, just do this: : +loop state @ 0= abort" *** no interpretation semantics for: +LOOP ***" postpone +loop ; immediate : ." state @ 0= abort" *** no interpretation semantics for: .quote ***" postpone ." ; immediate : ; state @ 0= abort" *** no interpretation semantics for: ; ***" postpone ; ; immediate : >r state @ 0= abort" *** no interpretation semantics for: >R ***" postpone >r ; immediate : abort" state @ 0= abort" *** no interpretation semantics for: ABORTquote ***" postpone abort" ; immediate : begin state @ 0= abort" *** no interpretation semantics for: BEGIN ***" postpone begin ; immediate : do state @ 0= abort" *** no interpretation semantics for: DO ***" postpone do ; immediate : does> state @ 0= abort" *** no interpretation semantics for: DOES> ***" postpone does> ; immediate : else state @ 0= abort" *** no interpretation semantics for: ELSE ***" postpone else ; immediate : exit state @ 0= abort" *** no interpretation semantics for: EXIT ***" postpone exit ; immediate : I state @ 0= abort" *** no interpretation semantics for: I ***" postpone I ; immediate : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate : J state @ 0= abort" *** no interpretation semantics for: J ***" postpone J ; immediate : leave state @ 0= abort" *** no interpretation semantics for: LEAVE ***" postpone leave ; immediate : literal state @ 0= abort" *** no interpretation semantics for: LITERAL ***" postpone literal ; immediate : loop state @ 0= abort" *** no interpretation semantics for: LOOP ***" postpone loop ; immediate : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate : r> state @ 0= abort" *** no interpretation semantics for: R> ***" postpone r> ; immediate : r@ state @ 0= abort" *** no interpretation semantics for: R@ ***" postpone r@ ; immediate : recurse state @ 0= abort" *** no interpretation semantics for: RECURSE ***" postpone recurse ; immediate : repeat state @ 0= abort" *** no interpretation semantics for: REPEAT ***" postpone repeat ; immediate : s" state @ 0= abort" *** no interpretation semantics for: Squote ***" postpone s" ; immediate : then state @ 0= abort" *** no interpretation semantics for: THEN ***" postpone then ; immediate : unloop state @ 0= abort" *** no interpretation semantics for: UNLOOP ***" postpone unloop ; immediate : until state @ 0= abort" *** no interpretation semantics for: UNTIL ***" postpone until ; immediate : while state @ 0= abort" *** no interpretation semantics for: WHILE ***" postpone while ; immediate : [ state @ 0= abort" *** no interpretation semantics for: [ ***" postpone [ ; immediate : ['] state @ 0= abort" *** no interpretation semantics for: ['] ***" postpone ['] ; immediate : [char] state @ 0= abort" *** no interpretation semantics for: [CHAR] ***" postpone [char] ; immediate : 2>r state @ 0= abort" *** no interpretation semantics for: 2>R ***" postpone 2>r ; immediate : 2r> state @ 0= abort" *** no interpretation semantics for: 2R> ***" postpone 2r> ; immediate : 2r@ state @ 0= abort" *** no interpretation semantics for: 2R@ ***" postpone 2r@ ; immediate : ?do state @ 0= abort" *** no interpretation semantics for: ?DO ***" postpone ?do ; immediate : again state @ 0= abort" *** no interpretation semantics for: AGAIN ***" postpone again ; immediate : c" state @ 0= abort" *** no interpretation semantics for: Cquote ***" postpone c" ; immediate : case state @ 0= abort" *** no interpretation semantics for: CASE ***" postpone case ; immediate : compile, state @ 0= abort" *** no interpretation semantics for: COMPILE, ***" postpone compile, ; immediate : endcase state @ 0= abort" *** no interpretation semantics for: ENDCASE ***" postpone endcase ; immediate : endof state @ 0= abort" *** no interpretation semantics for: ENDOF ***" postpone endof ; immediate : of state @ 0= abort" *** no interpretation semantics for: OF ***" postpone of ; immediate : [compile] state @ 0= abort" *** no interpretation semantics for: [COMPILE] ***" postpone [compile] ; immediate : 2literal state @ 0= abort" *** no interpretation semantics for: 2LITERAL ***" postpone 2literal ; immediate : fliteral state @ 0= abort" *** no interpretation semantics for: FLITERAL ***" postpone fliteral ; immediate : (local) state @ 0= abort" *** no interpretation semantics for: (LOCAL) ***" postpone (local) ; immediate : locals| state @ 0= abort" *** no interpretation semantics for: LOCALS| ***" postpone locals| ; immediate : ;code state @ 0= abort" *** no interpretation semantics for: ;CODE ***" postpone ;code ; immediate : ahead state @ 0= abort" *** no interpretation semantics for: AHEAD ***" postpone ahead ; immediate : cs-pick state @ 0= abort" *** no interpretation semantics for: CS-PICK ***" postpone cs-pick ; immediate : cs-roll state @ 0= abort" *** no interpretation semantics for: CS-ROLL ***" postpone cs-roll ; immediate : sliteral state @ 0= abort" *** no interpretation semantics for: SLITERAL ***" postpone sliteral ; immediate I will change my previous definition of SYNONYM to use these, so I get proper error-checking --- but I still have xt values that actually work.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-11 15:51 +0000 |
| Message-ID | <55294251.1311524850@news.eternal-september.org> |
| In reply to | #38112 |
On Fri, 10 Apr 2015 19:55:02 -0700 (PDT), hughaguilar96@gmail.com wrote: >On Tuesday, April 7, 2015 at 8:43:42 AM UTC-7, Stephen Pelc wrote: >> On Mon, 6 Apr 2015 18:09:39 -0700 (PDT), hughaguilar96@gmail.com >> wrote: >>=20 >> >I think that it should be an error to execute an immediate word in the o= >ute=3D >> >r-interpreter (STATE is zero).=20 >>=20 >> Why? >>=20 >> >This is almost always a mistake. >>=20 >> Why? > >In the past, people tried having one state-smart word that worked in both i= >nterpretive mode and compilation mode. For example, CHAR could be used eith= >er way. You talked about IMMEDIATE and made claims. Now you are talking about state-smart words. If I understand you, there's nothing wrong with executing an IMMEDIATE word interpretively, just in it being state-smart. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-11 16:25 -0700 |
| Message-ID | <2ff41461-4082-4897-a9a7-ca4bbf0bad91@googlegroups.com> |
| In reply to | #38125 |
On Saturday, April 11, 2015 at 8:51:05 AM UTC-7, Stephen Pelc wrote:
> On Fri, 10 Apr 2015 19:55:02 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
>
> >On Tuesday, April 7, 2015 at 8:43:42 AM UTC-7, Stephen Pelc wrote:
> >> On Mon, 6 Apr 2015 18:09:39 -0700 (PDT), hughaguilar96@gmail.com
> >> wrote:
> >>=20
> >> >I think that it should be an error to execute an immediate word in the o=
> >ute=3D
> >> >r-interpreter (STATE is zero).=20
> >>=20
> >> Why?
> >>=20
> >> >This is almost always a mistake.
> >>=20
> >> Why?
> >
> >In the past, people tried having one state-smart word that worked in both i=
> >nterpretive mode and compilation mode. For example, CHAR could be used eith=
> >er way.
>
> You talked about IMMEDIATE and made claims. Now you are talking about
> state-smart words. If I understand you, there's nothing wrong with
> executing an IMMEDIATE word interpretively, just in it being
> state-smart.
It is pretty much always a mistake to execute immediate words interpretively. They were obviously intended to be executed in compilation mode, because otherwise why would they have been made immediate? Almost all of the words in my list in the previous post will cause chaos if executed in interpretive mode --- that is why I added the ABORT" to them.
The only example I can think of in which an immediate word could be be executed meaningfully in interpretive mode is my MACRO: words. For example, I have this:
macro: on ( adr -- )
true swap ! ;
The user might not remember if this was written with MACRO: or with colon, but he will expect it to work in interpretive mode either way (if it was written with MACRO: as above, then it will be immediate).
This expectation can fail sometimes. For example, I may have written ON like this:
macro: on ( adr -- )
>r true r> ! ;
If this is executed in interpretive mode, it will fail because >R and R> are for use in compilation mode only. If >R doesn't have the ABORT" that I included recently, this may crash some Forth systems.
Just as a general rule of thumb, I would have the REPL always abort with an error message if it encounters an immediate word --- this is safer --- but I don't really care all that much, just so long as the dangerous ones (>R R> etc.) abort with an error message rather than crash the system.
I mostly use MACRO: in the novice-package to boost the speed. This use of MACRO: could be dispensed with given an optimizing compiler that automatically inlined short words. This is done by defining words with ICODE in SwiftForth; you may have something similar in VFX (I haven't really spent any time reading the manual). I'm not aware of any compiler that inlines short colon words though.
MACRO: is sometimes used in cases that colon can't be used. For example, in LIST.4TH I have these:
macro: next>r ( node -- node ) \ r: -- next-node
dup .fore @ >r ;
macro: each[ \ toucher: i*x node -- j*x
begin dup while
next>r ;
macro: ]each
r> repeat drop ;
Because of this kind of use, MACRO: can't be dispensed with entirely. Note that in my novice-package I deprecate the use of EACH[ and ]EACH and recommend EACH instead although it is slower.
Another example of MACRO: you may be interested in, is SORT in the novice package. Notice that I made HEAPIFY a macro so it could access the local variables of SORT. This can't be done with colon words. I actually wrote this code originally using colon words and global variables rather than local variables --- after it was debugged I rewrote it using macros and local variables to boost the speed --- when HEAPIFY was a colon word, I could test it in the REPL for debugging, but after I made it a macro I could no longer test it independently of SORT.
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-12 10:22 +0000 |
| Message-ID | <552a4707.387896@news.eternal-september.org> |
| In reply to | #38140 |
On Sat, 11 Apr 2015 16:25:58 -0700 (PDT), hughaguilar96@gmail.com wrote: >I mostly use MACRO: in the novice-package to boost the speed. This use of M= >ACRO: could be dispensed with given an optimizing compiler that automatical= >ly inlined short words. This is done by defining words with ICODE in SwiftF= >orth; you may have something similar in VFX (I haven't really spent any tim= >e reading the manual). I'm not aware of any compiler that inlines short col= >on words though. VFX does. Perhaps you should read more of the manual. 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-12 10:48 +0000 |
| Message-ID | <552a4d6f$0$3059$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #38148 |
In article <552a4707.387896@news.eternal-september.org>,
Stephen Pelc <stephen@mpeforth.com> wrote:
>On Sat, 11 Apr 2015 16:25:58 -0700 (PDT), hughaguilar96@gmail.com
>wrote:
>
>>I mostly use MACRO: in the novice-package to boost the speed. This use of M=
>>ACRO: could be dispensed with given an optimizing compiler that automatical=
>>ly inlined short words. This is done by defining words with ICODE in SwiftF=
>>orth; you may have something similar in VFX (I haven't really spent any tim=
>>e reading the manual). I'm not aware of any compiler that inlines short col=
>>on words though.
>
>VFX does. Perhaps you should read more of the manual.
>
>Stephen
ciforth does it on request by using :I instead of : like so
CREATE primes 1,000,000,000 ALLOT
:I p[] primes + ; \ Return the address of a flag whether i is prime.
The resulting word is a compiling word and IMMEDIATE , what Hugh
calls a macro.
As a service to myself, I execute the compiled behaviour when interpreting.
This fails for words like
:I FOR R> ;
:I NEXT R> 1- R> R@ UNTIL R> DROP ;
and wouldn't sit well with Anton Ertl, I guess.
I'm sure the huge package that ciforth is, has tricks for this too.
So again Hugh isn't much aware of what's available in the marketplace.
>
>--
>Stephen Pelc, stephenXXX@mpeforth.com
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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-12 10:53 +0000 |
| Message-ID | <552a4eb4$0$3059$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #38150 |
In article <552a4d6f$0$3059$e4fe514c@dreader35.news.xs4all.nl>,
Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>In article <552a4707.387896@news.eternal-september.org>,
>Stephen Pelc <stephen@mpeforth.com> wrote:
>>On Sat, 11 Apr 2015 16:25:58 -0700 (PDT), hughaguilar96@gmail.com
>>wrote:
>>
>>>I mostly use MACRO: in the novice-package to boost the speed. This use of M=
>>>ACRO: could be dispensed with given an optimizing compiler that automatical=
>>>ly inlined short words. This is done by defining words with ICODE in SwiftF=
>>>orth; you may have something similar in VFX (I haven't really spent any tim=
>>>e reading the manual). I'm not aware of any compiler that inlines short col=
>>>on words though.
>>
>>VFX does. Perhaps you should read more of the manual.
>>
>>Stephen
>
>ciforth does it on request by using :I instead of : like so
>
>CREATE primes 1,000,000,000 ALLOT
>:I p[] primes + ; \ Return the address of a flag whether i is prime.
>
>The resulting word is a compiling word and IMMEDIATE , what Hugh
>calls a macro.
>As a service to myself, I execute the compiled behaviour when interpreting.
>This fails for words like
> :I FOR R> ;
> :I NEXT R> 1- R> R@ UNTIL R> DROP ;
>and wouldn't sit well with Anton Ertl, I guess.
>
>I'm sure the huge package that ciforth is, has tricks for this too.
^^^^^^^
meant Marcel Hendrix's iforth ^^^^^^^ . ciforth isn't a huge package.
>So again Hugh isn't much aware of what's available in the marketplace.
>
>>
>>--
>>Stephen Pelc, stephenXXX@mpeforth.com
>
>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
>
--
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 | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-04-12 14:18 +0200 |
| Message-ID | <scom94jj7uk4$.i7op9u71jfw3.dlg@40tude.net> |
| In reply to | #38150 |
Op 12 Apr 2015 10:48:15 GMT schreef Albert van der Horst: > In article <552a4707.387896@news.eternal-september.org>, > Stephen Pelc <stephen@mpeforth.com> wrote: >>On Sat, 11 Apr 2015 16:25:58 -0700 (PDT), hughaguilar96@gmail.com >>wrote: >> >>>I mostly use MACRO: in the novice-package to boost the speed. This use of M= >>>ACRO: could be dispensed with given an optimizing compiler that automatical= >>>ly inlined short words. This is done by defining words with ICODE in SwiftF= >>>orth; you may have something similar in VFX (I haven't really spent any tim= >>>e reading the manual). I'm not aware of any compiler that inlines short col= >>>on words though. >> >>VFX does. Perhaps you should read more of the manual. >> >>Stephen > > ciforth does it on request by using :I instead of : like so > > CREATE primes 1,000,000,000 ALLOT >:I p[] primes + ; \ Return the address of a flag whether i is prime. > > The resulting word is a compiling word and IMMEDIATE , what Hugh > calls a macro. > As a service to myself, I execute the compiled behaviour when interpreting. > This fails for words like > :I FOR R> ; > :I NEXT R> 1- R> R@ UNTIL R> DROP ; Would this work in ciforth? I can't find :I :I FOR >R BEGIN ; :I NEXT R> 1- DUP >R 0= UNTIL RDROP ; > and wouldn't sit well with Anton Ertl, I guess. Gforth (and current CHForth) know about it: : FOR ]] >R BEGIN [[ ; IMMEDIATE : NEXT ]] R> 1- DUP >R 0= UNTIL RDROP [[ ; IMMEDIATE > > I'm sure the huge package that ciforth is, has tricks for this too. > So again Hugh isn't much aware of what's available in the marketplace. > >> >>-- >>Stephen Pelc, stephenXXX@mpeforth.com > > Groetjes Albert -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-04-12 14:35 +0200 |
| Message-ID | <xs2rj6cjgk7j$.1gix45a7e5pxm.dlg@40tude.net> |
| In reply to | #38153 |
Op Sun, 12 Apr 2015 14:18:45 +0200 schreef Coos Haak: > Op 12 Apr 2015 10:48:15 GMT schreef Albert van der Horst: > >> In article <552a4707.387896@news.eternal-september.org>, >> Stephen Pelc <stephen@mpeforth.com> wrote: >>>On Sat, 11 Apr 2015 16:25:58 -0700 (PDT), hughaguilar96@gmail.com >>>wrote: >>> >>>>I mostly use MACRO: in the novice-package to boost the speed. This use of M= >>>>ACRO: could be dispensed with given an optimizing compiler that automatical= >>>>ly inlined short words. This is done by defining words with ICODE in SwiftF= >>>>orth; you may have something similar in VFX (I haven't really spent any tim= >>>>e reading the manual). I'm not aware of any compiler that inlines short col= >>>>on words though. >>> >>>VFX does. Perhaps you should read more of the manual. >>> >>>Stephen >> >> ciforth does it on request by using :I instead of : like so >> >> CREATE primes 1,000,000,000 ALLOT >>:I p[] primes + ; \ Return the address of a flag whether i is prime. >> >> The resulting word is a compiling word and IMMEDIATE , what Hugh >> calls a macro. >> As a service to myself, I execute the compiled behaviour when interpreting. >> This fails for words like >> :I FOR R> ; >> :I NEXT R> 1- R> R@ UNTIL R> DROP ; > Would this work in ciforth? I can't find :I > :I FOR >R BEGIN ; > :I NEXT R> 1- DUP >R 0= UNTIL RDROP ; >> and wouldn't sit well with Anton Ertl, I guess. > Gforth (and current CHForth) know about it: > : FOR ]] >R BEGIN [[ ; IMMEDIATE > : NEXT ]] R> 1- DUP >R 0= UNTIL RDROP [[ ; IMMEDIATE : TEST 5 FOR R@ . NEXT ; --> 5 4 3 2 1 This is one type of FOR NEXT. Replace 0= by 0< --> 5 4 3 2 1 0 as does Gforth's own FOR NEXT. If FOR NEXT is used so much, why is there no standard behaviour? -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-13 12:36 +0000 |
| Message-ID | <2015Apr13.143658@mips.complang.tuwien.ac.at> |
| In reply to | #38154 |
Coos Haak <chforth@hccnet.nl> writes:
>If FOR NEXT is used so much, why is there no standard behaviour?
Does the premise hold?
In any case, FOR...NEXT has not been standardized, because there was
no proposal for standardizing it. If there was such a proposal, it
could only hope for acceptance with different names, because there is
conflicting practice for the existing names FOR and NEXT.
- 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-13 06:00 -0700 |
| Message-ID | <d5a215b2-0aa2-4e1f-8305-af947764827a@googlegroups.com> |
| In reply to | #38170 |
On Monday, 13 April 2015 13:39:53 UTC+1, Anton Ertl wrote: > Coos Haak <> writes: > >If FOR NEXT is used so much, why is there no standard behaviour? > > Does the premise hold? > > In any case, FOR...NEXT has not been standardized, because there was > no proposal for standardizing it. If there was such a proposal, it > could only hope for acceptance with different names, because there is > conflicting practice for the existing names FOR and NEXT. > > - 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/ It's trivial to define it in terms of DO and +LOOP (if you want the Chuck Moore, back-counting behaviour), or DO and LOOP if you the up-counting behaviour. As Anton says, there's no agreed standard, and since it's so trivial to implement, you'd just roll your own in 30 seconds and be done with it. Here's one I just knocked up (in 30 seconds) for my Forth 83 system. Implementing via DO/LOOP/+LOOP is nice because you inherit I and J. : for ( n -- ) compile lit 0 , compile swap [compile] do ; immediate : next ( -- ) compile lit -1 , [compile] +loop ; immediate : test 10 for i . next ; test 10 9 8 7 6 5 4 3 2 1 0 ok:0
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2015-04-13 21:02 +0200 |
| Message-ID | <8kda348zzp02$.18o57go9ukily.dlg@40tude.net> |
| In reply to | #38171 |
Op Mon, 13 Apr 2015 06:00:57 -0700 (PDT) schreef Mark Wills: > On Monday, 13 April 2015 13:39:53 UTC+1, Anton Ertl wrote: >> Coos Haak <> writes: >>>If FOR NEXT is used so much, why is there no standard behaviour? >> >> Does the premise hold? >> >> In any case, FOR...NEXT has not been standardized, because there was >> no proposal for standardizing it. If there was such a proposal, it >> could only hope for acceptance with different names, because there is >> conflicting practice for the existing names FOR and NEXT. >> >> - 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/ > > It's trivial to define it in terms of DO and +LOOP (if you want > the Chuck Moore, back-counting behaviour), or DO and LOOP if you > the up-counting behaviour. As Anton says, there's no agreed standard, > and since it's so trivial to implement, you'd just roll your own > in 30 seconds and be done with it. > > Here's one I just knocked up (in 30 seconds) for my Forth 83 system. > > Implementing via DO/LOOP/+LOOP is nice because you inherit I and J. > >: for ( n -- ) > compile lit 0 , > compile swap > [compile] do > ; immediate > >: next ( -- ) > compile lit -1 , > [compile] +loop > ; immediate > >: test 10 for i . next ; > test > 10 9 8 7 6 5 4 3 2 1 0 > ok:0 Chuck Moore would never define FOR in terms of DO, rather the other way round, or even omit DO-LOOP. There remains ambiguity when defining : T 5 FOR R@ . NEXT ; does it print 5 4 3 2 1 or 5 4 3 2 1 0 There is also this: 5 FOR AFT R@ . THEN NEXT giving 4 3 2 1 vs. 4 3 2 1 0 So, let's forget the whole issue. -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-04-13 13:32 -0700 |
| Message-ID | <6f1bb8cc-c2d1-4212-b9d0-df58034294b8@googlegroups.com> |
| In reply to | #38174 |
Agreed. It's a mess. Let's drop it!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-12 09:40 -0700 |
| Message-ID | <c9719961-6968-4d6a-a46b-77528d50aaba@googlegroups.com> |
| In reply to | #38150 |
Earlier I said this to Jason: On Thursday, April 2, 2015 at 9:04:42 PM UTC-7, hughag...@gmail.com wrote: > Jason, you are making a big mistake by accepting a language standard that is owned by a vendor --- you can't claim to be a Forth programmer either, unless you buy their product --- this is corruption of the language-standard concept. > > Using Gforth will not make you a Forth programmer --- Gforth is incompatible with both SwiftForth and VFX (although not in the same way). > > With Forth-200x, we are rapidly getting to the point where there effectively is no Forth language-standard at all, but if you don't use SwiftForth or VFX then you are denounced as being non-standard and not a Forth programmer at all --- this is despite the fact that SwiftForth and VFX are not compatible with each other --- ultimately, Leon Wagner and Stephen Pelc are on the Forth-200x committee and they say who is a Forth programmer and who isn't. Now we have Albert telling me that I'm not a Forth programmer at all because I'm not aware of what is in the "marketplace." On Sunday, April 12, 2015 at 3:48:16 AM UTC-7, Albert van der Horst wrote: > So again Hugh isn't much aware of what's available in the marketplace. Albert, you have already admitted to being a Wikipedia editor: https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic/kjeAwWCaR1MJ Only total losers write Wikipedia articles --- so, your criticism is meaningless to me.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-12 13:38 -0400 |
| Message-ID | <mgeagb$64v$1@dont-email.me> |
| In reply to | #38156 |
On 4/12/2015 12:40 PM, hughaguilar96@gmail.com wrote: > Earlier I said this to Jason: > On Thursday, April 2, 2015 at 9:04:42 PM UTC-7, hughag...@gmail.com wrote: >> Jason, you are making a big mistake by accepting a language standard that is owned by a vendor --- you can't claim to be a Forth programmer either, unless you buy their product --- this is corruption of the language-standard concept. >> >> Using Gforth will not make you a Forth programmer --- Gforth is incompatible with both SwiftForth and VFX (although not in the same way). >> >> With Forth-200x, we are rapidly getting to the point where there effectively is no Forth language-standard at all, but if you don't use SwiftForth or VFX then you are denounced as being non-standard and not a Forth programmer at all --- this is despite the fact that SwiftForth and VFX are not compatible with each other --- ultimately, Leon Wagner and Stephen Pelc are on the Forth-200x committee and they say who is a Forth programmer and who isn't. > > Now we have Albert telling me that I'm not a Forth programmer at all because I'm not aware of what is in the "marketplace." I notice you didn't quote Albert, but rather only yourself. I guess that is because a quote would dispel your hallucinations. > On Sunday, April 12, 2015 at 3:48:16 AM UTC-7, Albert van der Horst wrote: >> So again Hugh isn't much aware of what's available in the marketplace. > > Albert, you have already admitted to being a Wikipedia editor: > https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic/kjeAwWCaR1MJ > Only total losers write Wikipedia articles --- so, your criticism is meaningless to me. Lol. Writing about something you know makes you less knowledgeable? -- Rick
[toc] | [prev] | [next] | [standalone]
Page 11 of 17 — ← Prev page 1 … 9 10 [11] 12 13 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web