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 16 of 17 — ← Prev page 1 … 14 15 [16] 17 Next page →
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2015-04-10 17:52 +0200 |
| Message-ID | <5527f1cd$0$2937$e4fe514c@news2.news.xs4all.nl> |
| In reply to | #37880 |
Albert van der Horst wrote:
> We already have been over this. You can't define SYNONYM in ISO Forth.
> It requires carnal knowledge. So how would you call some one who still
> tries?
Well, I know of the complexities concerning e.g. IMMEDIATE words. And then
we have our flawed "FIND" to reckon with. This is the best I could come up
with:
: (FIND) BL WORD FIND SWAP ; \ (factored word)
(FIND) [UNDEFINED] DROP 0= [IF] \ COMUS
: [UNDEFINED] (FIND) DROP 0= ; IMMEDIATE
[THEN]
\ SEARCH EXT
[UNDEFINED] ALIAS [IF]
: ALIAS CREATE , DOES> @ EXECUTE ;
[THEN]
\ COMUS
[UNDEFINED] AKA [IF]
: AKA (FIND) OVER 0= ABORT" Undefined word" ALIAS 0> IF IMMEDIATE THEN ;
[THEN]
I have no doubt whatsoever that someone will come up with some kind of
scheme that will make it fail. But there's something else. "AKA" works
because it can parse a word, look it up and decide whether it will
call "ALIAS" or not.
In "SYNONYM" that is the /second/ action. Sure, defining first is much
easier for the mind (*), but the problem with "SYNONYM" is that you've
parsed something you cannot process right away. "Well, swallow it" I was
told when this came to voting - so I did. If you want to use it with 4tH
you will have to use the preprocessor so it can turn your:
SYNONYM new existing
Into a much more compiler friendly:
AKA existing new
Have it your way! ;-)
Hans Bezemer
(*) I'd rather have had "CLONE" than "AKA", because "CLONE" implies your
cloning something and make a copy, where the natural order of AKA is ("Real
name" AKA "Alias name") and not (AKA "Real name" "Alias name").
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-04-10 16:13 +0000 |
| Message-ID | <5527f695$0$2986$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #38086 |
In article <5527f1cd$0$2937$e4fe514c@news2.news.xs4all.nl>,
Hans Bezemer <the.beez.speaks@gmail.com> wrote:
>Albert van der Horst wrote:
>> We already have been over this. You can't define SYNONYM in ISO Forth.
>> It requires carnal knowledge. So how would you call some one who still
>> tries?
>Well, I know of the complexities concerning e.g. IMMEDIATE words. And then
>we have our flawed "FIND" to reckon with. This is the best I could come up
>with:
>
>: (FIND) BL WORD FIND SWAP ; \ (factored word)
>
>(FIND) [UNDEFINED] DROP 0= [IF] \ COMUS
>: [UNDEFINED] (FIND) DROP 0= ; IMMEDIATE
>[THEN]
> \ SEARCH EXT
>[UNDEFINED] ALIAS [IF]
>: ALIAS CREATE , DOES> @ EXECUTE ;
>[THEN]
> \ COMUS
>[UNDEFINED] AKA [IF]
>: AKA (FIND) OVER 0= ABORT" Undefined word" ALIAS 0> IF IMMEDIATE THEN ;
>[THEN]
>
>I have no doubt whatsoever that someone will come up with some kind of
>scheme that will make it fail. But there's something else. "AKA" works
>because it can parse a word, look it up and decide whether it will
>call "ALIAS" or not.
>
>In "SYNONYM" that is the /second/ action. Sure, defining first is much
>easier for the mind (*), but the problem with "SYNONYM" is that you've
>parsed something you cannot process right away. "Well, swallow it" I was
>told when this came to voting - so I did. If you want to use it with 4tH
>you will have to use the preprocessor so it can turn your:
>
> SYNONYM new existing
>
>Into a much more compiler friendly:
>
> AKA existing new
>
>Have it your way! ;-)
>
>Hans Bezemer
>
>(*) I'd rather have had "CLONE" than "AKA", because "CLONE" implies your
>cloning something and make a copy, where the natural order of AKA is ("Real
>name" AKA "Alias name") and not (AKA "Real name" "Alias name").
>
The least confusion still comes with ALIAS
'APE ALIAS MONKEY
ALIAS defines a new word. All defining words are followed directly
by the name we are defining, so its behaviour is highly expected.
'APE is not parsing a string. It states "get me the dictionary entry of
APE ". Reading 'APE you see that it is a denotation 1] so you know APE must
exist or you get an exception.
Groetjes Albert
1] At last I found out. Denotation is algol68 terminology. "In other
languages it is called a literal or constant"
A denotation gives a literal or constant of some sort. The
interpretation behaviour is to put it on the stack, the compilation
behaviour is to compile code to put it on the stack. In this way it is
a generalisation of numbers.
--
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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-11 16:56 -0700 |
| Message-ID | <220de181-4d12-4554-84a0-e80ae3b780eb@googlegroups.com> |
| In reply to | #37880 |
On Friday, April 3, 2015 at 3:48:32 AM UTC-7, Albert van der Horst wrote:
> We already have been over this. You can't define SYNONYM in ISO Forth.
> It requires carnal knowledge. So how would you call some one who still
> tries?
I would use the term "programmer" to describe such a person.
Here is a new version (called ALIAS rather than SYNONYM so as not to clash with my previous SYNONYM):
1234512345 constant alias-id
0
w field alias.adr
w field alias.id
w field alias.xt
constant alias-struct
: alias ( wid -- ) \ stream: new-name old-name
get-current swap set-current create set-current
here , alias-id ,
'find if immediate then ,
does>
alias.xt @ execute ;
: >body ( xt -- adr )
>body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if
r> alias.xt @ >body exit then then
r> ;
Now it is possible to make an alias of a word defined by CREATE and have >BODY work correctly on it. DEFER and IS can be defined as usual and they will work (these are already in the novice-package).
All of the above code was so trivial that I wrote it in about 10 minutes and it worked the first time. :-D
Here is a test of my code under VFX:
get-current alias ddd dup ok
5 ddd .s
DATA STACK
top
5 0000:0005
5 0000:0005
ok-2
2drop ok
get-current alias my-if if ok
: ttt my-if ." true" else ." false" then ; ok
1 ttt true ok
0 ttt false ok
create ccc 98765 , ok
get-current alias bbb ccc ok
bbb @ . 98765 ok
' bbb >body @ . 98765 ok
defer vvv ok
: hhh cr ." hello" ; ok
' hhh is vvv ok
vvv
hello ok
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-12 09:28 -0700 |
| Message-ID | <7f315edb-7223-49cb-aabf-c1b691b0d9cf@googlegroups.com> |
| In reply to | #38142 |
On Saturday, April 11, 2015 at 4:56:31 PM UTC-7, hughag...@gmail.com wrote:
> On Friday, April 3, 2015 at 3:48:32 AM UTC-7, Albert van der Horst wrote:
> > We already have been over this. You can't define SYNONYM in ISO Forth.
> > It requires carnal knowledge. So how would you call some one who still
> > tries?
>
> I would use the term "programmer" to describe such a person.
>
> Here is a new version (called ALIAS rather than SYNONYM so as not to clash with my previous SYNONYM):
> ...
> All of the above code was so trivial that I wrote it in about 10 minutes and it worked the first time. :-D
I wrote that code somewhat quickly. Here is a new version that is more readable. It is also slightly faster because ALIAS.XT is the first field in the struct and so no addition is required. Once again, all comments have been removed so the lines don't wrap (a fully commented version will be available in the next novice-package release).
1234512345 constant alias-id
0
w field alias.xt
w field alias.adr
w field alias.id
: alias ( wid -- ) \ stream: new-name old-name
get-current swap set-current create set-current
here >r alias-struct allot
'find if immediate then r@ alias.xt !
r@ r@ alias.adr !
alias-id r@ alias.id !
rdrop
does>
alias.xt @ execute ;
: >body ( xt -- adr )
>body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if
r> alias.xt @ >body exit then then
r> ;
Here are DEFER and IS which are already in the novice package:
: bad-vector
true abort" *** uninitialized vector ***" ;
: defer ( -- ) \ stream: name
create ['] bad-vector ,
does>
@ execute ;
: is ( xt -- ) \ stream: name
state @ if
postpone [']
postpone >body
!,
else
' >body ! then ;
immediate
I don't use DEFER and IS myself because they are inefficient. VECTOR is much better:
: <vector> { name | xt -- }
here ['] bad-vector , to xt
c" is-" name get-current :2name \ runtime: xt --
xt lit, !, ;,
name get-current :name \ runtime: -- \runtime runtime: i*x -- j*x
state@, if, xt lit, postpone lit, postpone @, postpone execute,
else, xt lit, @, execute, then, ;,
immediate
;
: vector ( -- )
bl word hstr dup >r <vector> r> dealloc ;
[toc] | [prev] | [next] | [standalone]
| From | Jason Damisch <jasondamisch@yahoo.com> |
|---|---|
| Date | 2015-04-03 10:26 -0700 |
| Message-ID | <d6f4cd39-cdc0-48d4-acee-f92b0680dab2@googlegroups.com> |
| In reply to | #37864 |
On Thursday, April 2, 2015 at 9:04:42 PM UTC-7, hughag...@gmail.com wrote: > > Because you have your own Forth written in Flat Assembler, maybe you can > > just use that Forth and move on? > If my Forth is not standard, then I can no longer claim to be a Forth programmer --- this is very bad for me, because I've been a Forth programmer for 30 years and Forth programming is something that I'm good at. Well, I'm not going to necessarily buy into the idea that the language vendors are evil. But, if you want my opinion, you should make up your own mind as to what Forth is and what it isn't. If you can write you own Forth, and it would be recognizable to the people who implemented Forths back in the 1970's and 1980's then I would call it a Forth. Nobody tells me what Forth is or what Forth isn't. I think for myself and I have my own mind. > 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. I never accepted a language standard or didn't accept a language standard. Please don't send out signals on this new group insinuating what I am or am not, or telling people what I am or am not. Someday I may implement my own Forth using Flat Assembler, or another assembler. I think that would be the ultimate exercise in the creative use of a computer, be it for commercial or hobby use. I may expect that my Forth, if I did share it publicly, would be accepted by some people, and ridiculed by other. I would have to distance myself such that I would not care one way or another what people think. > Using Gforth will not make you a Forth programmer --- Gforth is incompatible with both SwiftForth and VFX (although not in the same way). Using any Forth will make you a Forth programmer. > Anyway, Jason, why do you care? You are a website programmer; Forth is just a hobby for you. If you brown-nose the Forth-200x committee, they will let you claim to be a Forth programmer, and if you stop brown-nosing them, then you will stop being a Forth programmer --- but you're not writing Forth programs anyway, so what difference would it make one way or the other? I don't care what other people think. I just use Forth and enjoy it. Jason
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-04-05 21:54 -0700 |
| Message-ID | <d3df46e6-5158-4c09-b94b-65e8730f3c10@googlegroups.com> |
| In reply to | #37864 |
On Thursday, April 2, 2015 at 9:04:42 PM UTC-7, hughag...@gmail.com wrote: > On Thursday, April 2, 2015 at 9:04:24 AM UTC-7, Jason Damisch wrote: > > On Tuesday, March 31, 2015 at 3:13:14 PM UTC-7, hughag...@gmail.com wrote: > > > > > Actually, I have already figured out a way to work around this bug. > > When I said that I had figured out a way to work around the bug, I meant that I did this in ANS-Forth --- I save the name of the word and so the synonym (of an immediate word) can EVALUATE it --- but this is late-binding, which is a problem. > > Saving the xt so the synonym (of an immediate word) can EXECUTE it is the correct way to implement SYNONYM (this is the way that it has been implemented for about 30 years, ever since the first implementation came out in "Forth Dimensions") --- but this doesn't work under VFX, which is why I say that VFX has a bug. Well, Elizabeth Rather's pointless restrictions in ANS-Forth had me confused for a while! I was going to implement SYNONYM using EVALUATE and late-binding, but that wasn't necessary --- I figured out how to do it correctly saving the xt and using EXECUTE for early-binding --- so the ANS-Forth committee has been defeated again!
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-26 01:20 +0200 |
| Message-ID | <mhh7d9$b49$1@dont-email.me> |
| In reply to | #37787 |
Anton Ertl wrote: > If you want to tighten the standard to allow ' S", SwiftForth and VFX > do it wrongly. Probably. But Gforth does it wrong, too, because dual-xt is just another bad idea. The conclusion of our last discussion was that a recognizer for string literals is probably the right idea for the problem of S". > So systems have bugs. It's a bit odd to say that the systems have bugs when the first workaround for these bugs came years *after* the standard. In fact, the argument that the STATE-smart S" is non-standard even though STATE and IMMEDIATE are standard words was discovered later, after you fell into other STATE-smart pitholes, and started to think about the whole concept. It's ridiculous to assume that the Forth-94 standard team wanted this result. They all implemented their S" STATE-smart. It was an accidential result. > We papered over these bugs by making ' S" etc. > non-standard, and we can leave it at that. But somebody asked for a > discussion. If you want to tighten the standard and want to allow ' S" > in standard programs, the result should work in the use 2 of COMPILE,. No, that's your minority position. There's no consensus emerging for that position. >>3. dual-xt has been critisized by Stephen Pelc, because it breaks the >>conceptual unit of name and xt (where the xt is just a token for the name) > > There is no such unity in the standard, as evidenced by the definition > of FIND. That was a courtesy to Chuck Moore for cmForth; at that time it didn't feel right to have Chuck's then-current Forth being non-standard (now, Chuck has ColorForth, and nobody cares that it is non-standard; it has an entirely different approach at this problem: Color). The rational however tells a different story: "A.3.1.3.5 Execution tokens The association between an execution token and a definition is static. Once made, it does not change with changes in the search order or anything else. However it may not be unique, e.g., the phrases ’ 1+ and ’ CHAR+ might return the same value." That describes a clear n:1 relation between names and xt; the n for names comes through aliases, now called SYNONYM. That rational obviously has the concept of only one xt per definition. > One may find having several xts inelegant, but as long as we > have words like S", it's the way to go. [A.]3.1.3.5 probable needs some rewriting to actually say what an xt is supposed to really be... > Wasn't it you who claimed that nobody uses ' S" etc., so not doing the > right thing for ' S" etc. is ok? If you are right, no code will > break. There is - right now - no "right thing" for ' S". There are several popular systems with clearly different behavior, and the current standard allows these different behaviors. There may be non-portable code that only works with one or the other form. Non-portable code is not broken as such, as long as it is intented to be non-portable. IMHO, allowing different behaviors in the long run is a bad idea, but as long as no consensus emerged, we have no other option. >>The smart COMPILE, did not cause any problems with my code, even though >>I'm exactly doing this case 2) thing, which is the case where your >>concerns are really really big. > > Well, STATE-smartness also did not cause problems for you, so it's not > like you detect all problems. Well, it did not create problems, because I had a mental model for STATE- smart words, and therefore I know what they can do, and what they can't, thus they don't cause problems. I certainly didn't have a mental model for smart COMPILE, at that time, so I couldn't anticipate problems. When I ported MINOS to VFX, I didn't even know that there was a smart COMPILE, available. I didn't want to write code that is VFX-only. > We also have to take the conceptual burden on the programmers into > account. If you "tighten" the xt, EXECUTE and COMPILE, such that use > 2 works for some xts, but not for others (and probably without a test > whether an xt belongs to the use-2 class or not), the standard becomes > messy. Maybe. That would require a header flag (similar to compile-only). While you can easily check what SET-COMPILER xt a word has, it doesn't help you when you want to decide whether this word has no special compilation semantics. > May be a better tightening idea is to require ' S" etc. to produce an > error, in preparation for phasing S" etc. out. I have no good idea > how to tighten FIND, though. ' S" producing an error in Gforth could be doable, for other Forth systems, that's up to the implementer. > Tightening towards VFX's current implementation is not a good way to > tighten the standard, as it outlaws use 2. It doesn't outlaw use 2. It just allows ' on words where ' isn't defined now, because you possibly can't EXECUTE those xts (or COMPILE, them with the expected result). So it moves the problematic point from ' to the use 2 of COMPILE,. Use 2 isn't allowed for immediate compile-only words *now*. And users can easily create their own immediate compile-only words, and fail to mark them compile-only, because that's not a standard function. > As are different early/late binding semantics. In the combination with words with special compilation semantics, and an OOF which allows arbitrary xts to be assigned to a method. >>> So it seems that you suggest that SET-COMPILER and the like will never >>> be standardized. Fine with me. >> >>I don't suggest this. The question of SET-COMPILER is about emerging >>consensus. At the moment, we only have a very inadequate standard mean >>for users to write their own words with special compilation semantics, and >>that one must go. > > We have no standard for that. Sure, we have STATE and IMMEDIATE. And with the current set of restrictions for these words, that's actually allowed. You can write your own S" with standard means, i.e. STATE and IMMEDIATE. >>I won't support dual-xt. > > "One vote against would still be a rough consensus." Stephen Pelc also was pretty clear that in his oppinion dual-xt is an abomination. That's two votes. >>If a consensus emerges, we can narrow that down to one option. > > As long as we keep S" etc, the right way to implement these words is > dual-xt. I also doubt that you can convince Forth, Inc. and the large > number of traditional systems to switch to a different way. > > Therefore I think the way to find consensus is to get rid of S" etc. > Then we can get rid of dual-xt, Yes. > STATE-smart words, Not so quickly, because users create them, and there is a legacy codebase using them. You at least need to provide an alternative for that. > and the non-use2-compatible xts of VFX. No, we can't. All those compile-only words are non-use2-compatible; for different reasons, but there, the late-binding part is the one which doesn't work as expected. And that's not limited to VFX. You are always dodging them. This problem is not limited to S", UNLOOP and EXIT have pretty closely related problems. Try this: require mini-oof.fs object class method foo end-class foo-c ' ;s foo-c defines foo foo-c new constant foo-x : test1 foo-x foo ." bar" ; : test2 [ foo-c :: foo ] ." bar" ; test1 bar ok test2 ok oops, or rather OOPs... ;-). Let's assume you actually want to do that, have an early-exit method, which works both early and late-bound, you can do that, using SET-COMPILER (or the syntactic sugar COMP:). :noname rdrop rdrop ; comp: drop postpone exit ; foo-c defines foo : test1 foo-x foo ." bar" ; : test2 [ foo-c :: foo ] ." bar" ; test1 ok test2 ok : test3 test1 ." x " test2 ." y " ; ok test3 x y ok That's an example where SET-COMPILER actually allows you to create a word which does behave as expected. It requires carnal knowledge of the OOF system in question, and return stack trickery, and won't work with mini- oof2.fs, but that's it. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-26 15:09 +0000 |
| Message-ID | <2015Apr26.170950@mips.complang.tuwien.ac.at> |
| In reply to | #38403 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> If you want to tighten the standard to allow ' S", SwiftForth and VFX
>> do it wrongly.
>
>Probably. But Gforth does it wrong, too, because dual-xt is just another
>bad idea.
Could you give an argument why you think that.
>> So systems have bugs.
>
>It's a bit odd to say that the systems have bugs when the first workaround
>for these bugs came years *after* the standard.
It is not unusual for early implementations of a standard to have
bugs, and it also happens for later implementations. But cmForth came
years before the standard.
>> We papered over these bugs by making ' S" etc.
>> non-standard, and we can leave it at that. But somebody asked for a
>> discussion. If you want to tighten the standard and want to allow ' S"
>> in standard programs, the result should work in the use 2 of COMPILE,.
>
>No, that's your minority position. There's no consensus emerging for that
>position.
So you claim that the majority position is to break the programs that
use COMPILE, as in use 2. I really have my doubts that you will find
a majority for breaking programs, but in any case, I think that we
should stick to technical arguments here.
>>>3. dual-xt has been critisized by Stephen Pelc, because it breaks the
>>>conceptual unit of name and xt (where the xt is just a token for the name)
>>
>> There is no such unity in the standard, as evidenced by the definition
>> of FIND.
>
>That was a courtesy to Chuck Moore for cmForth; at that time it didn't feel
>right to have Chuck's then-current Forth being non-standard (now, Chuck has
>ColorForth, and nobody cares that it is non-standard; it has an entirely
>different approach at this problem: Color). The rational however tells a
>different story:
>
>"A.3.1.3.5 Execution tokens
>
>The association between an execution token and a definition is static. Once
>made, it does not change with changes in the search order or anything else.
>However it may not be unique, e.g., the phrases
>’ 1+ and
>’ CHAR+
>might return the same value."
>
>That describes a clear n:1 relation between names and xt; the n for names
>comes through aliases, now called SYNONYM. That rational obviously has the
>concept of only one xt per definition.
The section that it relates to says:
|3.1.3.5 Execution tokens
|
|Different definitions may have the same execution token if the
|definitions are equivalent.
|
|See: A.3.1.3.5 Execution tokens
So this section and its rationale describe the exception to the
principle that for each execution token there is one definition. It
does not say anything about getting from the name/definition to the
execution token. That is covered in the specification of FIND, and
there it is obvious that there can be two different xts.
|6.1.1550 FIND
|
|[...]For a given string, the values returned by FIND while compiling may
|differ from those returned while not compiling.
>> Wasn't it you who claimed that nobody uses ' S" etc., so not doing the
>> right thing for ' S" etc. is ok? If you are right, no code will
>> break.
>
>There is - right now - no "right thing" for ' S".
The right thing is to work both in use 1 and in use 2.
>There are several popular
>systems with clearly different behavior, and the current standard allows
>these different behaviors.
What the current standard allows is a red herring when it comes to
discussing tightening it.
>>>The smart COMPILE, did not cause any problems with my code, even though
>>>I'm exactly doing this case 2) thing, which is the case where your
>>>concerns are really really big.
>>
>> Well, STATE-smartness also did not cause problems for you, so it's not
>> like you detect all problems.
>
>Well, it did not create problems, because I had a mental model for STATE-
>smart words, and therefore I know what they can do, and what they can't,
>thus they don't cause problems.
That's not a basis for an interface for general use.
>> May be a better tightening idea is to require ' S" etc. to produce an
>> error, in preparation for phasing S" etc. out. I have no good idea
>> how to tighten FIND, though.
>
>' S" producing an error in Gforth could be doable, for other Forth systems,
>that's up to the implementer.
Sure, any tightening in this area requires that the implementer does
something.
>> Tightening towards VFX's current implementation is not a good way to
>> tighten the standard, as it outlaws use 2.
>
>It doesn't outlaw use 2. It just allows ' on words where ' isn't defined
>now, because you possibly can't EXECUTE those xts (or COMPILE, them with the
>expected result). So it moves the problematic point from ' to the use 2 of
>COMPILE,.
None of the current use 2 cases says: "You can only use this code with
some xts, but not with others (see Bernd Paysan's unwritten tightening
of ' for details)." Instead, they work with all standard xts. That
would no longer hold if we tighten toward VFX's current
implementation. In that sense these uses would be broken.
>Use 2 isn't allowed for immediate compile-only words *now*. And users can
>easily create their own immediate compile-only words, and fail to mark them
>compile-only, because that's not a standard function.
Users cannot create compile-only words in standard programs, because
there is no standard way to do that. And for the xt of user-defined
words (including immediate words), use 2 works even on VFX:
: foo ." foo" ; immediate
: test2 [ ' foo compile, ] ;
: test1 ['] foo execute ;
test1
test2
Both test words output FOO.
>>>I don't suggest this. The question of SET-COMPILER is about emerging
>>>consensus. At the moment, we only have a very inadequate standard mean
>>>for users to write their own words with special compilation semantics, and
>>>that one must go.
>>
>> We have no standard for that.
>
>Sure, we have STATE and IMMEDIATE. And with the current set of restrictions
>for these words, that's actually allowed. You can write your own S" with
>standard means, i.e. STATE and IMMEDIATE.
You then get a STATE-smart immediate word, not a word with special
compilation semantics. Unlike for the system's S", you can tell the
difference for the S" you defined yourself, because you are allowed to
tick and POSTPONE the user-defined S".
>> Therefore I think the way to find consensus is to get rid of S" etc.
>> Then we can get rid of dual-xt,
>
>Yes.
>
>> STATE-smart words,
>
>Not so quickly, because users create them, and there is a legacy codebase
>using them. You at least need to provide an alternative for that.
The alternative is recognizers.
Yes, the standard will contain STATE (as well as S" etc.) for some
time, but we can declare it obsolescent. If users create STATE-smart
words, it's their own fault, but at least systems can do without them
and without any of the alternatives that many don't like, either.
>> and the non-use2-compatible xts of VFX.
>
>No, we can't. All those compile-only words are non-use2-compatible; for
>different reasons, but there, the late-binding part is the one which doesn't
>work as expected.
: if1 postpone if ; immediate
: test3 [ ' if1 compile, ] ; immediate
: test4 ['] if1 execute ; immediate
: foo3 test3 . then ;
: foo4 test4 . then ;
see foo3
see foo4
Works nicely in Gforth, VFX, and in SwiftForth. So there are
compile-only words that can be use2-compatible, if the system
implements this stuff in the right way. On VFX IF (as provided by the
system) is not use2-compatible at the moment, but as IF1 demonstrates,
this is due to the implementation, not due to the inherent properties
of IF.
>And that's not limited to VFX. You are always dodging
>them. This problem is not limited to S", UNLOOP and EXIT have pretty
>closely related problems.
>
>Try this:
>
>require mini-oof.fs
>object class
>method foo
>end-class foo-c
>' ;s foo-c defines foo
>foo-c new constant foo-x
>: test1 foo-x foo ." bar" ;
>: test2 [ foo-c :: foo ] ." bar" ;
>
>test1 bar ok
>test2 ok
>
>oops, or rather OOPs... ;-).
Not really sure what you are trying to demonstrate, ;S is
non-standard, and nobody proposes standardizing it. It's also not
compile-only. But it takes a value from the return stack, and looking
at the stack effect should ring the alarm bells; yes, UNLOOP and EXIT
are in the same category. BTW, if we had a TAIL-EXECUTE, mini-oof
could be written not just to be faster, but it would even work with ;S
(at least on one system).
>Let's assume you actually want to do that, have an early-exit method, which
>works both early and late-bound, you can do that, using SET-COMPILER (or the
>syntactic sugar COMP:).
>
>:noname rdrop rdrop ; comp: drop postpone exit ; foo-c defines foo
>: test1 foo-x foo ." bar" ;
>: test2 [ foo-c :: foo ] ." bar" ;
>
>test1 ok
>test2 ok
>: test3 test1 ." x " test2 ." y " ; ok
>test3 x y ok
>
>That's an example where SET-COMPILER actually allows you to create a word
>which does behave as expected. It requires carnal knowledge of the OOF
>system in question, and return stack trickery, and won't work with mini-
>oof2.fs, but that's it.
Or you decide that it's better to use THROW and CATCH or some other
higher-level way to avoid all these problems.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-27 03:13 +0200 |
| Message-ID | <mhk2eh$mgb$1@dont-email.me> |
| In reply to | #38614 |
Anton Ertl wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>> If you want to tighten the standard to allow ' S", SwiftForth and VFX >>> do it wrongly. >> >>Probably. But Gforth does it wrong, too, because dual-xt is just another >>bad idea. > > Could you give an argument why you think that. A number of arguments have been raised: FIND becomes STATE-smart, resulting in surprises The non-tickability of a number of CORE words is a result of the interpretation that leads to dual-xt, and the non-tickability is "funny", because e.g. ' UNLOOP COMPILE, actually works fine The relation of name to xt is complex, and complex is bad Dual-xt is a nightmare in combination with CREATE DOES>, while SET-COMPILER is straight-forward >>> So systems have bugs. >> >>It's a bit odd to say that the systems have bugs when the first workaround >>for these bugs came years *after* the standard. > > It is not unusual for early implementations of a standard to have > bugs, and it also happens for later implementations. But cmForth came > years before the standard. Well, it is pretty obvious that the TC's intention was *not* to outlaw STATE-smart implementations of S" and TO. That was an accident. That means it was a bug in the standard, not in the programs. You have a fundamentalist approach to the Forth-94 text, so you separate the text from the authors and their intentions. However, you can not have a rough consensus without knowing what you do. So this fundamentalist approach is a contradiction to the process of how a standard gets decided. According to the slide Paul Bennett showed us last EuroForth, nearly half of all bugs are spec bugs. That's true for all the standardization work, too. A typical academic approach at spec bugs is that the spec by definition is bug-free. That's pretty far from reality. Acording to the Forth-2012 standard, Gforth's SUBSTITUTE implementation, which works fine for in-place substitutions, and therefore doesn't report an error, is, following the letters of the standard, a bug in Gforth. So doing it right is a bug, yes? No, it's a bug in the standard. >>No, that's your minority position. There's no consensus emerging for that >>position. > > So you claim that the majority position is to break the programs that > use COMPILE, as in use 2. I really have my doubts that you will find > a majority for breaking programs, but in any case, I think that we > should stick to technical arguments here. I'm tired of this straw-man, because I've repeated the arguments against several times: 1. These programs are non-standard now. 2. These prgrams not only are non-standard, the actual behavior between implementations is divergent, so it's really non-portable, not just hypothetical. Having divergent behaviour means that tightening the standard potentially breaks one or the other's code. 3. The typical use case for use 2 (e.g. OOF) is not affected, because those packages usually use :NONAME to create the xts. >>There is - right now - no "right thing" for ' S". > > The right thing is to work both in use 1 and in use 2. You can have your Anton-Forth standard where you are the only person with a vote. > What the current standard allows is a red herring when it comes to > discussing tightening it. Well, all reasons put aside, it's obvious only the Anton-Forth standard which matters. If reasons matters, then of course tightening up a spec means that you reduce the currently allowed number of options. For me, it seems that the only controversy about that topic is within one implementation team. I hope you do realize, that your EuroForth presentation why STATE-smart is evil and what to do about it triggered Stephen Pelc and MPE to develop the SET-COMPILER approach, and that approach was useful way beyond a replacement for STATE-smart for them. >>Well, it did not create problems, because I had a mental model for STATE- >>smart words, and therefore I know what they can do, and what they can't, >>thus they don't cause problems. > > That's not a basis for an interface for general use. That was just an explanation why I don't have problems with STATE-smart. I understand the concept of a word that depends on a global state, and can estimate the consequences. My mental model is pretty simple: text compilation is only meaningful in compile state, text interpretation is only meaningful in interpretation state. This is all you need to know to avoid the problems of STATE-smartness. > None of the current use 2 cases says: "You can only use this code with > some xts, but not with others (see Bernd Paysan's unwritten tightening > of ' for details)." Instead, they work with all standard xts. That > would no longer hold if we tighten toward VFX's current > implementation. In that sense these uses would be broken. Actually, it's not quite like that. There are (somewhat implicit) rules which words can be ticked, and which can't. Most Forth systems don't enforce these rules, which is very typical for Forth. So use 2 works only when you follow the unwritten Anton Ertl rules which words you are allowed to tick. On the other hand, the rule when your COMPILE, equivalence holds is pretty straight-forwardly extracted out of each standard glossary: As long as there's neither a special compilation semantics nor a statement that "interpretation semantics are undefined". That's true right now, because right now, in those cases, ticking isn't allowed. But in most systems, this doesn't result in an error. This means the Anton Ertl rules which words aren't allowed to be ticked, and the Bernd Paysan rules which words you can't expect to hold the Anton Ertl COMPILE, equivalence are actually identical. For the user, there is no difference. The SET-COMPILER definition of COMPILE, is pretty straight-forward: "perform the compilation semantics associated with xt". If it's default compilation semantics, it's the same as now. If there's a non-default compilation semantics (or there's no interpretation semantics), it is actually meaningful. It isn't now, because you aren't allowed to tick those words, you are supposed to FIND them, and in that case, the xt in compilation state is allowed to differ (on that potentially different xt, COMPILE, is then meaningful). >>Use 2 isn't allowed for immediate compile-only words *now*. And users can >>easily create their own immediate compile-only words, and fail to mark >>them compile-only, because that's not a standard function. > > Users cannot create compile-only words in standard programs, because > there is no standard way to do that. Doesn't matter, there are a number of words that are compile-only by having no meaningful interpretation semantics, and users can for sure write such words which have no meaningful interpretation semantics. > And for the xt of user-defined > words (including immediate words), use 2 works even on VFX: > > : foo ." foo" ; immediate > : test2 [ ' foo compile, ] ; > : test1 ['] foo execute ; > test1 > test2 > > Both test words output FOO. : foo state @ 0= IF -14 throw THEN ." foo" ; immediate That's the closest approach how a user can write compile-only word, and it fails both your tests, at run-time. > You then get a STATE-smart immediate word, not a word with special > compilation semantics. Unlike for the system's S", you can tell the > difference for the S" you defined yourself, because you are allowed to > tick and POSTPONE the user-defined S". You misrepresent the word "allowed" here. You certainly can tick and postpone S" in SwiftForth, VFX, and Gforth, none of those fail with an error. The disallowing is just to tell you "if you do that, expect non- portable results". And indeed, that's what you get. If you define your user-defined STATE-smart S" replacement, you can tick and postpone S", and you get portable results (i.e. your replacement behaves the same way on all three systems, though it's a way you don't like). > The alternative is recognizers. If you limit yourself to the S" or TO case, and ignore the syntax change. But STATE-smart is used for a lot of other things, and there, recognizer is not the universal solution. BerndOOF e.g. has a number of STATE-smart words (every class and object pointer is a state-smart definition), and converting that to e.g. a dot-parser recognizer would mean syntax change for a support library. Syntax changes break existing code, so a lot of further changes ripple through to do that change. On the other hand, with smart COMPILE, I can change BerndOOF to remove all the STATE-smartness without syntax change. This is very compelling. Since these are all CREATE DOES> words now, and the dual-xt approach on those was pretty much a failure (too complicated to use), dual-xt is not quite an option. >>No, we can't. All those compile-only words are non-use2-compatible; for >>different reasons, but there, the late-binding part is the one which >>doesn't work as expected. > > : if1 postpone if ; immediate > : test3 [ ' if1 compile, ] ; immediate > : test4 ['] if1 execute ; immediate > : foo3 test3 . then ; > : foo4 test4 . then ; > see foo3 > see foo4 > > Works nicely in Gforth, VFX, and in SwiftForth. Straw man, because ' IF EXECUTE shall be equivalent to encountering IF in interpetation state (that's what the standard says). I.e. both test3 and test4 fail to produce -14 THROW, and therefore show that you did something else. IF has no interpretation semantics. What you have done is to create an IF1 which has an interpretation semantics which is identical to IF's compilation semantics. That "fixed" the problem. You dodged the question: you fixed the problem by taking away the compile-only property and then said "there's no problem". You seem to miss the bigger picture. Forth is more than COMPILE, equals ]] LITERAL EXECUTE [[ Howewer, such an IF1 is not desireable, because it doesn't do propper error reporting. >>And that's not limited to VFX. You are always dodging >>them. This problem is not limited to S", UNLOOP and EXIT have pretty >>closely related problems. >> >>Try this: >> >>require mini-oof.fs >>object class >>method foo >>end-class foo-c >>' ;s foo-c defines foo >>foo-c new constant foo-x >>: test1 foo-x foo ." bar" ; >>: test2 [ foo-c :: foo ] ." bar" ; >> >>test1 bar ok >>test2 ok >> >>oops, or rather OOPs... ;-). > > Not really sure what you are trying to demonstrate, ;S is > non-standard, and nobody proposes standardizing it. You could use EXIT instead, but EXIT is compile-only in Gforth, so it can't be ticked, and therefore the example fails to compile. Just assume a tickable, non-immediate EXIT, as many other Forths have it. The point here is that your equivalence doesn't even hold for a simple word like ;S. It's not state-smart. It even works that way: : test ['] ;s execute ." foo" ; test ok It just doesn't work with the method call. Sure, it's the return stack why, but that's also the reason for it being compile-only. > It's also not > compile-only. But it takes a value from the return stack, and looking > at the stack effect should ring the alarm bells; yes, UNLOOP and EXIT > are in the same category. BTW, if we had a TAIL-EXECUTE, mini-oof > could be written not just to be faster, but it would even work with ;S > (at least on one system). mini-oof also could have a macro-expanding METHOD, in which case it would also work with ;S, at least in Gforth. The reason why UNLOOP and other return stack manipulating words are compile- only is exactly that return stack effect. > Or you decide that it's better to use THROW and CATCH or some other > higher-level way to avoid all these problems. The main purpose for SET-COMPILER is optimization, and well, this certainly would be an optimization. This is an example where you have optimizations which only work in a particular context (method call late/early). -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-01 14:59 +0000 |
| Message-ID | <2015May1.165908@mips.complang.tuwien.ac.at> |
| In reply to | #38624 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Anton Ertl wrote:
>>>> If you want to tighten the standard to allow ' S", SwiftForth and VFX
>>>> do it wrongly.
>>>
>>>Probably. But Gforth does it wrong, too, because dual-xt is just another
>>>bad idea.
>>
>> Could you give an argument why you think that.
>
>A number of arguments have been raised:
>
>FIND becomes STATE-smart, resulting in surprises
I don't remember any surprises. But yes, the FIND interface was
designed for counted strings and single-xt+immediate words, and does
not quite fit the Forth-94/2012 concepts, resulting in the state-smart
description, among other things. It should be updated. An updated
replacement is:
find-name ( c-addr u -- nt | 0 )
No STATE-smartness there.
>The non-tickability of a number of CORE words is a result of the
>interpretation that leads to dual-xt, and the non-tickability is "funny",
>because e.g. ' UNLOOP COMPILE, actually works fine
It is a result of the Forth-94 goal that such words may be implemented
as immediate or non-immediate words (e.g., EXIT is implemented as
immediate compile-only, and UNLOOP is a normal word). We could have
implemented ' EXIT as producing an xt, but then ' EXIT EXECUTE would
have been equivalent to POSTPONE EXIT, unlike for UNLOOP; so you could
not use the xt portably, because the xt would reflect the
implementation.
Anyway, I see no direct connection to dual-xt. You can implement
ticking of such words on dual-xt systems, and you can implement an
error on ticking such words on single-xt systems.
>The relation of name to xt is complex, and complex is bad
It reflects the complexity of the concepts in the standard. If you
have two semantics (interpretation and compilation semantics), which
may be arbitrarily unrelated, you need two reifications of them: the
execution toklen (for interpretation/execution semantics), and the
compilation token (for compilation semantics).
The relation is as simple as the words NAME>INTERPRET and NAME>COMPILE
that are already in the standard.
If we want it simpler, let us get rid of the two unrelated semantics;
then we can return to single-xt-with-immediate (and maybe
compile-only) flags.
>Dual-xt is a nightmare in combination with CREATE DOES>, while SET-COMPILER
>is straight-forward
You can use a SET-COMPILER-like interface for setting the compilation
semantics in a dual-xt system, and you get the same "straight-forward"
usage.
I am sceptical about the usefulness of defining words for words with
arbitrary combinations of interpretation and compilation semantics,
though. I think we have too many such words already, no need to
define more.
>I hope you do realize, that your EuroForth
>presentation why STATE-smart is evil and what to do about it triggered
>Stephen Pelc and MPE to develop the SET-COMPILER approach, and that approach
>was useful way beyond a replacement for STATE-smart for them.
Yes, SET-COMPILER is useful for code generation. However, it is a
good solution only for code generation. It is not a solution for
implementing arbitrary combinations of interpretation and compilation
semantics, and the reason is similar to the STATE-smartness problem:
While it works for the text-interpreter, it fails in other contexts
(although differently from STATE-smart words).
>> None of the current use 2 cases says: "You can only use this code with
>> some xts, but not with others (see Bernd Paysan's unwritten tightening
>> of ' for details)." Instead, they work with all standard xts. That
>> would no longer hold if we tighten toward VFX's current
>> implementation. In that sense these uses would be broken.
>
>Actually, it's not quite like that. There are (somewhat implicit) rules
>which words can be ticked, and which can't. Most Forth systems don't
>enforce these rules, which is very typical for Forth. So use 2 works only
>when you follow the unwritten Anton Ertl rules which words you are allowed
>to tick.
There is actually a written rule in Forth-94/2012:
|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;
BTW, the mentioning of FIND here means that a text interpreter cannot
be a standard program (at least not when you pass such a word to it).
Ouch. But we better deal with that in another discussion.
In any case, in every Forth except VFX, use 2 works with all xts you
can get, including the non-standard cases. I'll deal with your ;S
example below.
>On the other hand, the rule when your COMPILE, equivalence holds is pretty
>straight-forwardly extracted out of each standard glossary: As long as
>there's neither a special compilation semantics nor a statement that
>"interpretation semantics are undefined". That's true right now, because
>right now, in those cases, ticking isn't allowed. But in most systems, this
>doesn't result in an error.
>
>This means the Anton Ertl rules which words aren't allowed to be ticked, and
>the Bernd Paysan rules which words you can't expect to hold the Anton Ertl
>COMPILE, equivalence are actually identical. For the user, there is no
>difference.
>
>The SET-COMPILER definition of COMPILE, is pretty straight-forward: "perform
>the compilation semantics associated with xt".
That makes no sense, if you claim that we cannot get at the xt.
>>>Use 2 isn't allowed for immediate compile-only words *now*. And users can
>>>easily create their own immediate compile-only words, and fail to mark
>>>them compile-only, because that's not a standard function.
>>
>> Users cannot create compile-only words in standard programs, because
>> there is no standard way to do that.
>
>Doesn't matter, there are a number of words that are compile-only by having
>no meaningful interpretation semantics, and users can for sure write such
>words which have no meaningful interpretation semantics.
In any case, for now they don't have a standard means to write words
for which use 2 does not work.
>> And for the xt of user-defined
>> words (including immediate words), use 2 works even on VFX:
>>
>> : foo ." foo" ; immediate
>> : test2 [ ' foo compile, ] ;
>> : test1 ['] foo execute ;
>> test1
>> test2
>>
>> Both test words output FOO.
>
>: foo state @ 0= IF -14 throw THEN ." foo" ; immediate
>
>That's the closest approach how a user can write compile-only word, and it
>fails both your tests, at run-time.
: foo state @ 0= IF -14 throw THEN ." foo" ; immediate
: test2 [ ' foo compile, ] ;
: test1 ['] foo execute ;
test1
test2
Both test1 and test2 report a -14 error (on VFX), so this use 2 case
works correctly even on VFX. I see no failure here.
>> You then get a STATE-smart immediate word, not a word with special
>> compilation semantics. Unlike for the system's S", you can tell the
>> difference for the S" you defined yourself, because you are allowed to
>> tick and POSTPONE the user-defined S".
>
>You misrepresent the word "allowed" here. You certainly can tick and
>postpone S" in SwiftForth, VFX, and Gforth, none of those fail with an
>error. The disallowing is just to tell you "if you do that, expect non-
>portable results". And indeed, that's what you get.
>
>If you define your user-defined STATE-smart S" replacement, you can tick and
>postpone S", and you get portable results (i.e. your replacement behaves the
>same way on all three systems, though it's a way you don't like).
Yes. It works for use 1 and use 2.
>> The alternative is recognizers.
>
>If you limit yourself to the S" or TO case, and ignore the syntax change.
>But STATE-smart is used for a lot of other things, and there, recognizer is
>not the universal solution. BerndOOF e.g. has a number of STATE-smart words
>(every class and object pointer is a state-smart definition), and converting
>that to e.g. a dot-parser recognizer would mean syntax change for a support
>library. Syntax changes break existing code, so a lot of further changes
>ripple through to do that change.
You can leave the STATE-smart stuff in for the existing code (this
apparently works despite the STATE-smartness), and provide recognizers
for the new code.
>On the other hand, with smart COMPILE, I can change BerndOOF to remove all
>the STATE-smartness without syntax change. This is very compelling. Since
>these are all CREATE DOES> words now, and the dual-xt approach on those was
>pretty much a failure (too complicated to use), dual-xt is not quite an
>option.
As mentioned above, if you don't like the existing syntax, you can add
SET-COMPSEM that provides the same syntax as SET-COMPILER but changes
the compilation semantics instead of what COMPILE, does.
>>>No, we can't. All those compile-only words are non-use2-compatible; for
>>>different reasons, but there, the late-binding part is the one which
>>>doesn't work as expected.
>>
>> : if1 postpone if ; immediate
>> : test3 [ ' if1 compile, ] ; immediate
>> : test4 ['] if1 execute ; immediate
>> : foo3 test3 . then ;
>> : foo4 test4 . then ;
>> see foo3
>> see foo4
>>
>> Works nicely in Gforth, VFX, and in SwiftForth.
>
>Straw man, because ' IF EXECUTE shall be equivalent to encountering IF in
>interpetation state (that's what the standard says). I.e. both test3 and
>test4 fail to produce -14 THROW, and therefore show that you did something
>else.
Sure, the difference between IF and IF1 is that IF1 has interpretation
semantics; they are the same as the compilation semantics of IF, and
the xt you get behaves like what most people expect who write ' IF.
And this xt is nicely compatible with use 2.
So there is no fundamental reason why compile-only words are not
compatible with use 2; yes, VFX as currently implemented is not
use-2-compatible, but there is no reason to keep it that way. If we
see all current implementations as unchangeable, we don't need to talk
about tightening the standard.
Here's how VFX could change in a world where we only have
single-xt+immediate(+compile-only) words and use2 works universally:
Every word is tickable, and immediate-compile-only words provide a the
xt that, when EXECUTEd, performs the compilation semantics. IF would
be such a word. The system's text interpreter checks for compile-only
and reports an error if such a word is interpreted; newly written
user-defined text interpreters would also check for that (we would
provide a way to check for that). Old user-written text interpreters
would not report an error when interpreting IF; not a big issue IMO.
>>>And that's not limited to VFX. You are always dodging
>>>them. This problem is not limited to S", UNLOOP and EXIT have pretty
>>>closely related problems.
>>>
>>>Try this:
>>>
>>>require mini-oof.fs
>>>object class
>>>method foo
>>>end-class foo-c
>>>' ;s foo-c defines foo
>>>foo-c new constant foo-x
>>>: test1 foo-x foo ." bar" ;
>>>: test2 [ foo-c :: foo ] ." bar" ;
>>>
>>>test1 bar ok
>>>test2 ok
>>>
>>>oops, or rather OOPs... ;-).
>>
>> Not really sure what you are trying to demonstrate, ;S is
>> non-standard, and nobody proposes standardizing it.
>
>You could use EXIT instead, but EXIT is compile-only in Gforth, so it can't
>be ticked, and therefore the example fails to compile. Just assume a
>tickable, non-immediate EXIT, as many other Forths have it.
>
>The point here is that your equivalence doesn't even hold for a simple word
>like ;S. It's not state-smart.
The equivalence does hold. The problem is that ;S consumes the return
address, and the two contexts (the one where EXECUTE is and the one
where the result of the COMPILE, ends up) are different in this
respect. If you really wanted to use ;S as a method, you could change
mini-oof.fs appropriately (either use a TAIL-EXECUTE in METHOD, or
wrap the xt in a colon definition before COMPILE,ing it).
>It even works that way:
>
>: test ['] ;s execute ." foo" ;
>
>test ok
>
>It just doesn't work with the method call. Sure, it's the return stack why,
>but that's also the reason for it being compile-only.
But ;S is not compile-only.
>mini-oof also could have a macro-expanding METHOD, in which case it would
>also work with ;S, at least in Gforth.
Or that, yes.
>The main purpose for SET-COMPILER is optimization, and well, this certainly
>would be an optimization. This is an example where you have optimizations
>which only work in a particular context (method call late/early).
SET-COMPILER for optimization is fine, if it is really an
optimization, i.e., it is equivalent to the unoptimized case.
Something that works only in one context is a kludge, not an
optimization.
- 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-05-01 19:38 +0000 |
| Message-ID | <5543d3ae.886007148@news.eternal-september.org> |
| In reply to | #38750 |
On Fri, 01 May 2015 14:59:08 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >Yes, SET-COMPILER is useful for code generation. However, it is a >good solution only for code generation. It is not a solution for >implementing arbitrary combinations of interpretation and compilation >semantics, and the reason is similar to the STATE-smartness problem: >While it works for the text-interpreter, it fails in other contexts >(although differently from STATE-smart words). What does SET-COMPILER have to do with the text interpreter? AS MPE implements it, it has to do with what COMPILE, does. >>Actually, it's not quite like that. There are (somewhat implicit) rules >>which words can be ticked, and which can't. Most Forth systems don't >>enforce these rules, which is very typical for Forth. So use 2 works only >>when you follow the unwritten Anton Ertl rules which words you are allowed >>to tick. Unfortunately whether a word can be ticked is an implementation issue, not a standards issue. The standard uses wriggle words like "undefined" and "ambiguous condition", but it's an implementation issue as to whether tick actually works and as to whether a returned xt is meaningful. >BTW, the mentioning of FIND here means that a text interpreter cannot >be a standard program (at least not when you pass such a word to it). And I really, really object to the idea that you cannot write a text interpreter in standard Forth. If the standard actually means that, then the standard is wrong, wrong, wrong. 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-05-01 16:59 -0700 |
| Message-ID | <a63c60fa-6a86-426f-a2b8-c6c344972b0e@googlegroups.com> |
| In reply to | #38755 |
On Friday, May 1, 2015 at 12:38:02 PM UTC-7, Stephen Pelc wrote:
> On Fri, 01 May 2015 14:59:08 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
> >BTW, the mentioning of FIND here means that a text interpreter cannot
> >be a standard program (at least not when you pass such a word to it).
>
> And I really, really object to the idea that you cannot write
> a text interpreter in standard Forth. If the standard actually
> means that, then the standard is wrong, wrong, wrong.
This is disingenuous --- you are crying crocodile-tears all the way to the bank.
If you really believed this, then you would resign from the Forth-200x committee --- but instead you let Anton and Bernd turn the discussion into a scene from "Dumb and Dumber" while pretending to be opposed --- and eventually the sabotaged FIND gets incorporated into Forth-200x just like it was in ANS-Forth. At this time you proclaim that Forth-200x was the joint effort of the entire Forth community, and is intended to benefit the entire Forth community --- and, of course, you deny that I am a Forth programmer at all.
You are the only person to benefit from preventing common Forth programmers from writing a cross-compiler in standard Forth --- because you sell a cross-compiler written in VFX-specific Forth for big bucks --- and, ironically, you sell VFX on the basis that it is a standard-compliant Forth system.
Anyway --- I have defeated you with my disambiguifiers, such as this one for IF (the original bug I noticed in VFX):
: if state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate
This works fine. I demonstrated by writing SYNONYM SYNONYM-FAST and ALIAS using these disambiguifiers. You can't prevent me from disambiguifying ANS-Forth!!!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 15:56 +0000 |
| Message-ID | <2015May2.175606@mips.complang.tuwien.ac.at> |
| In reply to | #38755 |
stephen@mpeforth.com (Stephen Pelc) writes:
>On Fri, 01 May 2015 14:59:08 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Yes, SET-COMPILER is useful for code generation. However, it is a
>>good solution only for code generation. It is not a solution for
>>implementing arbitrary combinations of interpretation and compilation
>>semantics, and the reason is similar to the STATE-smartness problem:
>>While it works for the text-interpreter, it fails in other contexts
>>(although differently from STATE-smart words).
>
>What does SET-COMPILER have to do with the text interpreter? AS MPE
>implements it, it has to do with what COMPILE, does.
And if you limited yourself to doing that correctly, it would have
nothing special to do with the text interpreter. But then you could not
use it to implement tickable words with non-default compilation
semantics, e.g., a tickable version of S". You would need, e.g.,
SET-COMPSEM.
The use of SET-COMPILER for S" happens to work in the text
interpreter, and since ' S" is not allowed, that's good enough for the
standard usage of S". One does not notice that COMPILE, does not work
properly, because one cannot get an xt of such a word to pass to
COMPILE,. Without the non-ticking restriction, one could notice that
in a standard program.
>Unfortunately whether a word can be ticked is an implementation
>issue, not a standards issue. The standard uses wriggle words
>like "undefined" and "ambiguous condition", but it's an
>implementation issue as to whether tick actually works and as to
>whether a returned xt is meaningful.
No, the standard requires most words to be tickable. The exceptions
are words with undefined interpretation semantics, and words like S"
which are explicitly excluded.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-01 22:45 +0200 |
| Message-ID | <mi0oir$7j8$1@dont-email.me> |
| In reply to | #38750 |
Anton Ertl wrote: > I don't remember any surprises. Hm, just implement this : my' ( "name" -- xt ) bl word find 0= abort" not found" ; : [my'] ( "name -- ) \ runtime: ( -- xt ) my' postpone literal ; immediate : test" [my'] s" execute type ; test" blabla" :7: error: Stack underflow test" >>>blabla<<<" WTF? Shouldn't that work? Works fine in interpretation state: my' s" execute blabla" type blabla ok STATE-smart is just bad, no matter where you do it. > find-name ( c-addr u -- nt | 0 ) > > No STATE-smartness there. FIND-NAME shows that having a single token is a good idea. The open question here is: Why must a new token type be introduced? Why not make it possible to use xt? > It is a result of the Forth-94 goal that such words may be implemented > as immediate or non-immediate words (e.g., EXIT is implemented as > immediate compile-only, and UNLOOP is a normal word). We could have > implemented ' EXIT as producing an xt, but then ' EXIT EXECUTE would > have been equivalent to POSTPONE EXIT, unlike for UNLOOP; so you could > not use the xt portably, because the xt would reflect the > implementation. IMHO the problem here is immediacy, and the fact that an xt does not convey the information of immediacy. If we defined e.g. : IMMEDIATE ( -- ) immediate-bit set-flags \ legacy for FIND ['] execute set-compiler ; the xt could still be used without knowledge of the internal working. Since these words have no interpretation semantics, EXECUTing them has no standard meaning, but COMPILE, could be used for both immediate and non-immediate versions. > Anyway, I see no direct connection to dual-xt. You can implement > ticking of such words on dual-xt systems, and you can implement an > error on ticking such words on single-xt systems. my' exit >name .name compile-only-error ok : test [my'] exit >name .name ; ok test EXIT ok EXIT appears to be a dual-xt word in Gforth... at least for FIND. >>The relation of name to xt is complex, and complex is bad > > It reflects the complexity of the concepts in the standard. If you > have two semantics (interpretation and compilation semantics), which > may be arbitrarily unrelated, you need two reifications of them: the > execution toklen (for interpretation/execution semantics), and the > compilation token (for compilation semantics). "need" in mathematical terms is something that can't be done without. IMHO you either need two tokens, *or* you need to ways to deal with the single token. The SET-COMPILER COMPILE, ultimatively (when implemented with full consequence) provides a way to deal with the two semantics even when there's only one token. > The relation is as simple as the words NAME>INTERPRET and NAME>COMPILE > that are already in the standard. That's an abstraction over multiple possible ways to deal with that problem now. The question is: do we need the abstraction? If we implemented SET- COMPILER consequently, : name>interpret ( nt -- xt ) name> ; : name>compile ( nt -- xt1 xt2 ) name> ['] compile, ; with a simple NAME> could do the job. > If we want it simpler, let us get rid of the two unrelated semantics; > then we can return to single-xt-with-immediate (and maybe > compile-only) flags. Getting rid of the two unrelated semantics IMHO is wishful thinking. > You can use a SET-COMPILER-like interface for setting the compilation > semantics in a dual-xt system, and you get the same "straight-forward" > usage. Yes, that can be done *now*, with the new header in Gforth. This new header structure is a very powerful tool. > I am sceptical about the usefulness of defining words for words with > arbitrary combinations of interpretation and compilation semantics, > though. I think we have too many such words already, no need to > define more. We have such things in various OOF systems. We might challenge these OOF systems by providing simpler, more straight-forward ones (like mini-oof2, which does not need that stuff, and uses SET-COMPILER for optimization only), but as far as proposals in this direction went in the past, this resulted in https://xkcd.com/927/ > Yes, SET-COMPILER is useful for code generation. However, it is a > good solution only for code generation. It is not a solution for > implementing arbitrary combinations of interpretation and compilation > semantics, and the reason is similar to the STATE-smartness problem: > While it works for the text-interpreter, it fails in other contexts > (although differently from STATE-smart words). IMHO it only fails for the way you want COMPILE, to be read. That is part of the debate, IMHO it shouldn't have been formulated that way. > There is actually a written rule in Forth-94/2012: > > |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; > > BTW, the mentioning of FIND here means that a text interpreter cannot > be a standard program (at least not when you pass such a word to it). > Ouch. But we better deal with that in another discussion. Yes, ouch. > In any case, in every Forth except VFX, use 2 works with all xts you > can get, including the non-standard cases. I'll deal with your ;S > example below. The problem with that is that your definition of "xts you can get" only applies to ', not to FIND. And it doesn't work for the xts you can get with FIND. >>The SET-COMPILER definition of COMPILE, is pretty straight-forward: >>"perform the compilation semantics associated with xt". > > That makes no sense, if you claim that we cannot get at the xt. You can get every xt, if not with ', then with FIND. Writing a MY' that solves the "get the xt" problem is trivial, see above. >>Doesn't matter, there are a number of words that are compile-only by >>having no meaningful interpretation semantics, and users can for sure >>write such words which have no meaningful interpretation semantics. > > In any case, for now they don't have a standard means to write words > for which use 2 does not work. That's a "burying the tools" failure. > Both test1 and test2 report a -14 error (on VFX), so this use 2 case > works correctly even on VFX. I see no failure here. The failure here is rather that the user's intention (create a compile-only word) doesn't work. The problem is that the standard has such words, but the user can't create them, so you have a burrying the tools issue here. That should not be the case. The user should have the same capabilities of defining words as the system programmer has. >>If you define your user-defined STATE-smart S" replacement, you can tick >>and postpone S", and you get portable results (i.e. your replacement >>behaves the same way on all three systems, though it's a way you don't >>like). > > Yes. It works for use 1 and use 2. No, because it's state smart. It just copies the state-smart behavior. > Sure, the difference between IF and IF1 is that IF1 has interpretation > semantics; they are the same as the compilation semantics of IF, and > the xt you get behaves like what most people expect who write ' IF. > And this xt is nicely compatible with use 2. > > So there is no fundamental reason why compile-only words are not > compatible with use 2; Well, you just did take away the compile-only feature... now it's compatible with use 2. > yes, VFX as currently implemented is not > use-2-compatible, but there is no reason to keep it that way. If we > see all current implementations as unchangeable, we don't need to talk > about tightening the standard. > > Here's how VFX could change in a world where we only have > single-xt+immediate(+compile-only) words and use2 works universally: > Every word is tickable, and immediate-compile-only words provide a the > xt that, when EXECUTEd, performs the compilation semantics. IF would > be such a word. The system's text interpreter checks for compile-only > and reports an error if such a word is interpreted; I see an urge to duplicate Gforth's FIND behavior on these words, to provide error reporting in user-written text interpreters... > newly written > user-defined text interpreters would also check for that (we would > provide a way to check for that). Old user-written text interpreters > would not report an error when interpreting IF; not a big issue IMO. So you suggest to break old user-written text interpreters, because it's IYO not a big issue, and you usually don't write your own text interpreters? Maybe it's an issue, and you just don't know it. >>The point here is that your equivalence doesn't even hold for a simple >>word >>like ;S. It's not state-smart. > > The equivalence does hold. The problem is that ;S consumes the return > address, I've explaind it already, don't dodge this: The reason for EXIT (and it's primitive friend ;S) is compile-only is that it consumes the return address. In Gforth's text interpreter, where ;S simply works: ." foo" ;s ." bar" foo ok there's no reason to make it compile-only. > and the two contexts (the one where EXECUTE is and the one > where the result of the COMPILE, ends up) are different in this > respect. If you really wanted to use ;S as a method, you could change > mini-oof.fs appropriately (either use a TAIL-EXECUTE in METHOD, or > wrap the xt in a colon definition before COMPILE,ing it). Well, mini-oof2 has the fix ;-) end-class bar ' ;s bar is foo bar new constant x : test1 ." foo" foo ." bar" ; : test2 ." foo" [ bar :: foo ] ." bar" ; x .test1 foo ok x .test2 foo ok So yes, it is possible to let this equivalence hold. However, it's also possible to have an OOF where the much-wanted use 2 works even with VFX. Just define : :: ( object "name" -- ) >vt @ postpone literal postpone execute ; instead of : :: ( object "name" -- ) >vt @ compile, ; -- 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 | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2015-05-02 02:58 -0700 |
| Message-ID | <26db7026-2dff-4f10-9799-24ec3d9d9078@googlegroups.com> |
| In reply to | #38757 |
On Friday, 1 May 2015 21:45:15 UTC+1, Bernd Paysan wrote: > Anton Ertl wrote: > > STATE-smart is just bad, no matter where you do it. > This, very much. So long as STATE is exposed, people will write STATE-smart words. Why not start by making STATE obsolescent? FORTH Inc. managed well enough without it. The user should never need to know what STATE the compiler is in. All they need know is that the Standard words perform the specified compilation semantics and that, if they need to, they can extend the compiler by specifying how it should deal with a particular definition. Abolish hypochondriac code!
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-05-02 11:51 +0000 |
| Message-ID | <5544b8de.944678734@news.eternal-september.org> |
| In reply to | #38764 |
On Sat, 2 May 2015 02:58:27 -0700 (PDT), JennyB <jennybrien@googlemail.com> wrote: >This, very much. So long as STATE is exposed, people will write STATE-smart >words. Why not start by making STATE obsolescent? FORTH Inc. managed well >enough without it. The user should never need to know what STATE the >compiler is in. All they need know is that the Standard words perform the >specified compilation semantics and that, if they need to, they can extend the >compiler by specifying how it should deal with a particular definition. > >Abolish hypochondriac code! Be careful what you wish for. When writing what are now called "Domain Specific Languages" for end-users, state-smart words can be very useful. Yes, they can bite you, but a little documentation covers that. In shipping Forth compilers for 30+ years, I can only think of one support issue other than those generated by language lawyers. Note that I do not dispute that state-smart words are dangerous, only that the technique remains useful on some occasions. 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-05-02 12:25 +0000 |
| Message-ID | <5544c223$0$21273$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38764 |
In article <26db7026-2dff-4f10-9799-24ec3d9d9078@googlegroups.com>,
JennyB <jennybrien@googlemail.com> wrote:
>On Friday, 1 May 2015 21:45:15 UTC+1, Bernd Paysan wrote:
>> Anton Ertl wrote:
>
>>
>> STATE-smart is just bad, no matter where you do it.
>>
>
>This, very much. So long as STATE is exposed, people will write STATE-smart
>words. Why not start by making STATE obsolescent? FORTH Inc. managed well
>enough without it. The user should never need to know what STATE the
>compiler is in. All they need know is that the Standard words perform the
>specified compilation semantics and that, if they need to, they can extend the
>compiler by specifying how it should deal with a particular definition.
May I add to that.
The user should at all time be aware what state the system is in.
If (s)he doesn't know whether Forth is compiling or interpreting,
(s)he is in bad shape.
The only question is whether we need STATE to inspect.
Now we are at that. Is IF a compile-only word, that cannot be
sensibly used during interpretation? Well, lets compile a piece
of ciforth code by hand.
First defeat the "compiler security", otherwise IF just says
ERROR! COMPILE-ONLY (by inspecting STATE!)
'NOOP '?COMP 3 CELLS MOVE.
Now define
: AAP 1 IF "WE GAAN NAAR ROME" TYPE THEN ;
OK
SEE AAP
: AAP
1
0BRANCH [ 50 , ] ( between TYPE (;) )
[ "WE GAAN NAAR ROME" ] DLITERAL TYPE
;
Now lets do this by hand, (using a shitload of carnal knowledge)
HERE 'AAP >DFA !
OK
'LIT , 1 , IF .S "WE GAAN NAAR ROME" 'LIT , , 'LIT , , 'TYPE , .S THEN '(;) ,
S[ 2 ]
S[ 2 ]
SEE AAP
: AAP
1
0BRANCH [ 50 , ] ( between TYPE (;) )
[ "WE GAAN NAAR ROME" ] DLITERAL TYPE
;
OK
In the above, you could replace
IF
by
'IF EXECUTE
and replace , by COMPILE, IF you so wish.
So the "interpretation semantics" of an immediate word, is its
semantics full stop. You can execute it in interpretation state or
in compilation state, whatever you choose. That is the meaning of
immediate. Make sure you know what you're doing.
>
>Abolish hypochondriac code!
Is the above an example of that? Or is that trying to gain insight in
what actually happens during compilation?
I can't say I'm very concerned about STATE. It turns smart words into
leaky abstractions, true. Forth is one pile of leaky abstractions anyway,
one more doesn't hurt. Piling well-thought-out abstractions from LISP
onto Forth and see it leak, if not bleed, doesn't make me happy.
A similar process is going on with c. It was a simple language, now
they are piling abstractions onto it, resulting in "miscompilations"
of what was transparent code before.
With all the attention to state smart word, I'd say that is one of the
least likely traps a novice (tm by Hugh) would fall in.
My most favorite feature of Forth is transparency.
Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-02 16:45 +0000 |
| Message-ID | <2015May2.184502@mips.complang.tuwien.ac.at> |
| In reply to | #38764 |
JennyB <jennybrien@googlemail.com> writes:
>On Friday, 1 May 2015 21:45:15 UTC+1, Bernd Paysan wrote:
>> Anton Ertl wrote:
>
>>
>> STATE-smart is just bad, no matter where you do it.
>>
>
>This, very much. So long as STATE is exposed, people will write STATE-smart
>words. Why not start by making STATE obsolescent?
I have much sympathy for that, but I think Bernd Paysan would not like
it, because it would break his traditional text interpreter.
Nevertheless, let us think about how a modern text interpreter without
STATE might look like:
For a single word, let's start out with a version that still has state:
parse-name find-name dup 0= -13 and throw
state @ if
name>compile
else
name>interpret
then
execute
Numbers etc. are handled with recognizers and thus are also covered by
FIND-NAME etc.
Now let's get rid of state:
defer name>x \ not the Gforth word of the same name
: ] ['] name>compile is name>x ;
: [ ['] name>interpret is name>x ;
\ and here the text interpreter:
parse-name find-name dup 0= -13 and throw name>x execute
Nicely concise.
- 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-05-02 19:12 +0100 |
| Message-ID | <mi340d$o2b$1@dont-email.me> |
| In reply to | #38781 |
on 02/05/2015 17:45:01, wrote: > JennyB <jennybrien@googlemail.com> writes: >>On Friday, 1 May 2015 21:45:15 UTC+1, Bernd Paysan wrote: >>> Anton Ertl wrote: >> >>> >>> STATE-smart is just bad, no matter where you do it. >>> >> >>This, very much. So long as STATE is exposed, people will write STATE-smart >>words. Why not start by making STATE obsolescent? > > I have much sympathy for that, but I think Bernd Paysan would not like > it, because it would break his traditional text interpreter. > > Nevertheless, let us think about how a modern text interpreter without > STATE might look like: > > For a single word, let's start out with a version that still has > state: > > parse-name find-name dup 0= -13 and throw > state @ if > name>compile > else > name>interpret > then > execute > > Numbers etc. are handled with recognizers and thus are also covered by > FIND-NAME etc. > > Now let's get rid of state: > > defer name>x \ not the Gforth word of the same name >: ] ['] name>compile is name>x ; >: [ ['] name>interpret is name>x ; : [ ['] name>interpret is name>x ; immediate > > \ and here the text interpreter: > parse-name find-name dup 0= -13 and throw name>x execute > > Nicely concise. Which is exactly how my Forth works (excepting the NAME>xxx words; they're named differently). > > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-03 16:23 +0000 |
| Message-ID | <2015May3.182339@mips.complang.tuwien.ac.at> |
| In reply to | #38757 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> I don't remember any surprises.
>
>Hm, just implement this
>
>: my' ( "name" -- xt ) bl word find 0= abort" not found" ;
>: [my'] ( "name -- ) \ runtime: ( -- xt )
> my' postpone literal ; immediate
>
>: test" [my'] s" execute type ;
>
>test" blabla"
>:7: error: Stack underflow
>test" >>>blabla<<<"
>
>WTF? Shouldn't that work? Works fine in interpretation state:
>
>my' s" execute blabla" type blabla ok
Yet nobody has complained about that, so apparently nobody was
surprised.
But yes, I am all for making FIND obsolescent and replacing it with a
word that is more fitting for the standard concepts, such as
FIND-NAME.
>> find-name ( c-addr u -- nt | 0 )
>>
>> No STATE-smartness there.
>
>FIND-NAME shows that having a single token is a good idea. The open
>question here is: Why must a new token type be introduced? Why not make it
>possible to use xt?
It is possible to use xt, it's just not required. We had this
discussion when TRAVERSE-WORDLIST was proposed, no need to rehash it
now.
>> It is a result of the Forth-94 goal that such words may be implemented
>> as immediate or non-immediate words (e.g., EXIT is implemented as
>> immediate compile-only, and UNLOOP is a normal word). We could have
>> implemented ' EXIT as producing an xt, but then ' EXIT EXECUTE would
>> have been equivalent to POSTPONE EXIT, unlike for UNLOOP; so you could
>> not use the xt portably, because the xt would reflect the
>> implementation.
>
>IMHO the problem here is immediacy, and the fact that an xt does not convey
>the information of immediacy. If we defined e.g.
>
>: IMMEDIATE ( -- )
> immediate-bit set-flags \ legacy for FIND
> ['] execute set-compiler ;
>
>the xt could still be used without knowledge of the internal working. Since
>these words have no interpretation semantics, EXECUTing them has no standard
>meaning, but COMPILE, could be used for both immediate and non-immediate
>versions.
All user-defined immediate words and all the words that the standard
specifies as immediate have interpretation semantics, and your
IMMEDIATE just does not behave as specified by the standard. If you
replace SET-COMPILER with SET-COMPSEM, I think it would be correct. I
think one could implement the immediate-flag check of FIND by testing
whether the compsem field contains the xt of COMPILE,.
As for having an EXIT with an xt that cannot be EXECUTEd but can be
COMPILE,d, what's would that be good for? Why not just pass the
compilation token around and EXECUTE that?
>> Anyway, I see no direct connection to dual-xt. You can implement
>> ticking of such words on dual-xt systems, and you can implement an
>> error on ticking such words on single-xt systems.
>
>my' exit >name .name compile-only-error ok
>: test [my'] exit >name .name ; ok
>test EXIT ok
>
>EXIT appears to be a dual-xt word in Gforth... at least for FIND.
And yet the implementation of EXIT has only a single xt (plus
immediate and compile-only flags). If you don't like this behaviour
of FIND, there are also other options:
* FIND reports not-found when called in interpretation state; I would
find the resulting error message confusing, though.
* FIND ignores the compile-only flag and treats EXIT just as an
immediate word. A text interpreter based on that FIND would not
report an error if it encounters EXIT in interpretation state.
>>>The relation of name to xt is complex, and complex is bad
>>
>> It reflects the complexity of the concepts in the standard. If you
>> have two semantics (interpretation and compilation semantics), which
>> may be arbitrarily unrelated, you need two reifications of them: the
>> execution toklen (for interpretation/execution semantics), and the
>> compilation token (for compilation semantics).
>
>"need" in mathematical terms is something that can't be done without. IMHO
>you either need two tokens, *or* you need to ways to deal with the single
>token. The SET-COMPILER COMPILE, ultimatively (when implemented with full
>consequence) provides a way to deal with the two semantics even when there's
>only one token.
>
>> The relation is as simple as the words NAME>INTERPRET and NAME>COMPILE
>> that are already in the standard.
>
>That's an abstraction over multiple possible ways to deal with that problem
>now. The question is: do we need the abstraction? If we implemented SET-
>COMPILER consequently,
>
>: name>interpret ( nt -- xt ) name> ;
>: name>compile ( nt -- xt1 xt2 ) name> ['] compile, ;
>
>with a simple NAME> could do the job.
But you could no longer do what Stephen Pelc calls "interp-compile,",
and you could not use all xts for use2. You would have introduced two
kinds of xts: Those that can be used for use 2 (full xts), and those
that cannot (use-2-incompatible xts). Is that simplicity? Not in my
book.
>> If we want it simpler, let us get rid of the two unrelated semantics;
>> then we can return to single-xt-with-immediate (and maybe
>> compile-only) flags.
>
>Getting rid of the two unrelated semantics IMHO is wishful thinking.
I think it is doable, but you may be right that there will always be
programmers who will want to go in that direction, and use whatever
tools appear to give them that, however broken the results, such as
STATE or SET-COMPILER. So it may be better to give them a proper tool
for the job, such as SET-COMPSEM.
>> In any case, in every Forth except VFX, use 2 works with all xts you
>> can get, including the non-standard cases. I'll deal with your ;S
>> example below.
>
>The problem with that is that your definition of "xts you can get" only
>applies to ', not to FIND. And it doesn't work for the xts you can get with
>FIND.
No, it also works with all xts you can get with FIND. The only system
with a broken COMPILE, is VFX.
>>>The SET-COMPILER definition of COMPILE, is pretty straight-forward:
>>>"perform the compilation semantics associated with xt".
>>
>> That makes no sense, if you claim that we cannot get at the xt.
>
>You can get every xt, if not with ', then with FIND. Writing a MY' that
>solves the "get the xt" problem is trivial, see above.
If we can get at the xt, COMPILE, should work correctly for it. Then
implementing S" etc. with SET-COMPILER is a bug.
Somehow your arguments are contradictory: First you argue that we
cannot get at the xt of S", so we won't notice if COMPILE, does not
work correctly for it, and therefore using SET-COMPILER is acceptable.
Now you argue that we can get at the xt after all. In that case the
VFX implementation of S" is buggy.
>>>Doesn't matter, there are a number of words that are compile-only by
>>>having no meaningful interpretation semantics, and users can for sure
>>>write such words which have no meaningful interpretation semantics.
>>
>> In any case, for now they don't have a standard means to write words
>> for which use 2 does not work.
>
>That's a "burying the tools" failure.
It's a failure to let existing code continue to work?
>> Both test1 and test2 report a -14 error (on VFX), so this use 2 case
>> works correctly even on VFX. I see no failure here.
>
>The failure here is rather that the user's intention (create a compile-only
>word) doesn't work. The problem is that the standard has such words, but
>the user can't create them, so you have a burrying the tools issue here.
>That should not be the case. The user should have the same capabilities of
>defining words as the system programmer has.
Fine with me. Gforth gives them COMPILE-ONLY and INTERPRET/COMPILE:
etc. for that. If you don't like the existing dual-semantics words,
SET-COMPSEM might be an interface you like better.
>>>If you define your user-defined STATE-smart S" replacement, you can tick
>>>and postpone S", and you get portable results (i.e. your replacement
>>>behaves the same way on all three systems, though it's a way you don't
>>>like).
>>
>> Yes. It works for use 1 and use 2.
>
>No, because it's state smart. It just copies the state-smart behavior.
Yes, but it still works for both use 1 and use 2 as specified.
>> yes, VFX as currently implemented is not
>> use-2-compatible, but there is no reason to keep it that way. If we
>> see all current implementations as unchangeable, we don't need to talk
>> about tightening the standard.
>>
>> Here's how VFX could change in a world where we only have
>> single-xt+immediate(+compile-only) words and use2 works universally:
>> Every word is tickable, and immediate-compile-only words provide a the
>> xt that, when EXECUTEd, performs the compilation semantics. IF would
>> be such a word. The system's text interpreter checks for compile-only
>> and reports an error if such a word is interpreted;
>
>I see an urge to duplicate Gforth's FIND behavior on these words, to provide
>error reporting in user-written text interpreters...
>
>> newly written
>> user-defined text interpreters would also check for that (we would
>> provide a way to check for that). Old user-written text interpreters
>> would not report an error when interpreting IF; not a big issue IMO.
>
>So you suggest to break old user-written text interpreters, because it's IYO
>not a big issue, and you usually don't write your own text interpreters?
>Maybe it's an issue, and you just don't know it.
You mean there are programs out there that rely on getting a
compile-only error when they pass a compile-only word to a
user-written text interpreter? I doubt it, and in any case these
programs are not standard and would not work on, e.g., SwiftForth (for
which I have not seen any indication of any compile-only check at
all).
But if you really have the urge to have a Gforth-like FIND, why did
you give that as example of surprising behaviour earlier in your
posting?
Anyway, you don't want to go for single-xt+immediate+compile-only
anyway, so let's drop that.
>>>The point here is that your equivalence doesn't even hold for a simple
>>>word
>>>like ;S. It's not state-smart.
>>
>> The equivalence does hold. The problem is that ;S consumes the return
>> address,
>
>I've explaind it already, don't dodge this: The reason for EXIT (and it's
>primitive friend ;S) is compile-only is that it consumes the return address.
>In Gforth's text interpreter, where ;S simply works:
>
>." foo" ;s ." bar" foo ok
>
>there's no reason to make it compile-only.
So ;S is not compile-only, contrary to your claim. The reason why
EXIT is compile-only is that it is not implemented as a word with
default compilation semantics (unlike ;S), but as a compiling word.
>However, it's also
>possible to have an OOF where the much-wanted use 2 works even with VFX.
>Just define
>
>: :: ( object "name" -- ) >vt @ postpone literal postpone execute ;
>
>instead of
>
>: :: ( object "name" -- ) >vt @ compile, ;
I certainly won't slow down my OOP system on all systems just to work
around a bug in VFX. The workaround should be targetted at VFX, i.e.,
[defined] vfxforth [if]
: compile, postpone literal postpone execute ;
[then]
This does not fix VFX completely, because then use 1 of COMPILE, does
not work. I guess VFX as currently implemented is hopeless.
- 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]
Page 16 of 17 — ← Prev page 1 … 14 15 [16] 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web