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 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-17 08:49 -0700 |
| Message-ID | <6aa13579-7a14-4768-b82d-d41b3e6c3890@googlegroups.com> |
| In reply to | #39800 |
miercuri, 17 iunie 2015, 13:40:28 UTC+3, Anton Ertl a scris: > hughaguilar96@gmail.com writes: > >On Tuesday, June 16, 2015 at 12:21:58 AM UTC-7, Anton Ertl wrote: > >> Mark Wills <markwills1970@gmail.com> writes: > >> >The very idea that FIND can *find* some words, and not *find* others > >> >is preposterous. > >> > >> I find the search order quite useful, and :NONAME, too. > > > >What does this have to do with FIND aborting on IF and dozens of other words? > > Nothing. It has to do with the idea that Mark Wills finds > preposterous. > I really don't understand the idea either. However, I'm not a native english speaker...
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2015-06-17 13:50 -0700 |
| Message-ID | <41c7656a-8553-4153-abd7-78e939d391f7@googlegroups.com> |
| In reply to | #39805 |
On Wednesday, June 17, 2015 at 5:49:32 PM UTC+2, Raimond Dragomir wrote: [..] > I really don't understand the idea either. However, I'm not a > native english speaker... I am also not a native speaker but had no problem at all understanding the analogy. The problem must be elsewhere. -marcel
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-17 18:36 -0700 |
| Message-ID | <e9151d2a-2583-433f-a8f2-1ae08031d019@googlegroups.com> |
| In reply to | #39800 |
On Wednesday, June 17, 2015 at 3:40:28 AM UTC-7, Anton Ertl wrote: > hughaguilar96@gmail.com writes: > >On Tuesday, June 16, 2015 at 12:21:58 AM UTC-7, Anton Ertl wrote: > >> Mark Wills <markwills1970@gmail.com> writes: > >> >The very idea that FIND can *find* some words, and not *find* others > >> >is preposterous. > >> > >> I find the search order quite useful, and :NONAME, too. > > > >What does this have to do with FIND aborting on IF and dozens of other words? > > Nothing. It has to do with the idea that Mark Wills finds > preposterous. > > As for FIND aborting on IF, I don't know a Forth system that does > this. > > - anton I tested gForth v0.7.0. and found that tick aborts on IF and all those other words, but FIND finds them. That was unexpected. Back in 2009 when I discovered that tick aborted many of the words in the standard (IF and semicolon etc.), I assumed that FIND would abort too --- tick is normally defined in terms of FIND. The ANS-Forth document (4.1.2.) "Ambiguous Conditions" lists the following as an ambiguous condition: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." This would seem to indicate that tick and FIND would behave comparably when they attempt to obtain the execution token of a definition with undefined interpretation semantics. So, whether tick or FIND is used, it is an ambiguous condition. Section 3.4.4. describes what happens: 3.4.4 Possible actions on an ambiguous condition When an ambiguous condition exists, a system may take one or more of the following actions: - ignore and continue; - display a message; - execute a particular word; - set interpretation state and begin text interpretation; - take other implementation-defined actions; - take implementation-dependent actions. The response to a particular ambiguous condition need not be the same under all circumstances. That last sentence means that tick and FIND can respond differently from each other when looking up the same word --- tick aborts but FIND returns the xt --- they may do the opposite in the next version of gForth and that would be legal too. So, gForth isn't as badly crippled as I thought it was --- FIND does work but tick does not --- the programmer can't rely on this though, as pretty much anything is possible with an ambiguous condition. The ANS-Forth document makes it legal to "execute a particular word," which leaves a lot scary possibilities, such as return the correct xt 99% of the time and return a random xt 1% of the time (I can't be sure that gForth isn't currently doing this, as I haven't tested gForth thoroughly enough to be sure). If my disambiguifiers are used however, then tick and FIND will both return an xt (execution token) and the xt can be given to COMPILE, or EXECUTE for the correct result --- this will work on any ANS-Forth compliant compiler (past, present or future, written by sane or insane) because the disambiguifier uses POSTPONE which is exempt from section 4.1.2. (Ambiguous Conditions) --- dodging section 4.1.2. is why they are called "disambiguifiers."
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-17 23:44 -0700 |
| Message-ID | <a4671561-d16a-483e-8c0f-925fda7ab936@googlegroups.com> |
| In reply to | #39812 |
> The ANS-Forth document (4.1.2.) "Ambiguous Conditions" lists the following as an ambiguous condition: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." > I consider this a mistake. What's ambiguous in obtaining an xt? FIND, tick and co. should deliver an xt if the word is findable, simple as that. Oh, if the word doesn't have interpretation semantics (there may be "compile-only" words - ok) then the word itself may abort. ANS forth is too full of ambiguous conditions to be taken seriously. And it seems that even "major forth vendors" are doing just that: not taken ANS standard seriously. Personally I think that ANS was born just to be an umbrella for some forths at that time. Those forths had a lot of incompatibilities so the ANS was forced to "accomodate" these incompatibilities as "ambiguous conditions". And now it's easy to hide behind "ambiguous conditions" and claim that your system is standard.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-17 21:14 -1000 |
| Message-ID | <i6Kdnahgz55v8h_InZ2dnUU7-QWdnZ2d@supernews.com> |
| In reply to | #39814 |
On 6/17/15 8:44 PM, Raimond Dragomir wrote: >> The ANS-Forth document (4.1.2.) "Ambiguous Conditions" lists the following as an ambiguous condition: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics." >> > I consider this a mistake. What's ambiguous in obtaining an xt? FIND, tick and co. > should deliver an xt if the word is findable, simple as that. > Oh, if the word doesn't have interpretation semantics (there may be "compile-only" words - ok) > then the word itself may abort. > ANS forth is too full of ambiguous conditions to be taken seriously. And it > seems that even "major forth vendors" are doing just that: not taken ANS standard > seriously. > Personally I think that ANS was born just to be an umbrella for some forths > at that time. > Those forths had a lot of incompatibilities so the ANS was forced > to "accomodate" these incompatibilities as "ambiguous conditions". > And now it's easy to hide behind "ambiguous conditions" and claim that your > system is standard. > There is some truth in that, but the fact is that there is far more unanimity of usage after Forth94 than before, and that is a good thing, coupled with significant improvements in performance and new facilities (FP, host OS files, etc.). Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-18 00:15 -0700 |
| Message-ID | <d89f4639-7f06-45e3-9e6a-167ea46e4db8@googlegroups.com> |
| In reply to | #39814 |
On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: > And now it's easy to hide behind "ambiguous conditions" and claim that your > system is standard. Exactly. You could take (say) three Forth systems, all of which could exhibit different behaviour under certain conditions, and yet all of them would be "standard". So, your program *may* work as intended, or it *may* not. Given that the purpose of the standard is to promote portability, it's not a very good state of affairs, especially after some 30 odd years. > Personally I think that ANS was born just to be an umbrella for some forths > at that time. > Those forths had a lot of incompatibilities so the ANS was forced > to "accomodate" these incompatibilities as "ambiguous conditions". I agree. And we're still living with the effects.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-18 09:27 +0100 |
| Message-ID | <mltvap$9o6$1@dont-email.me> |
| In reply to | #39817 |
on 18/06/2015 08:15:47, Mark Wills wrote: > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: >> And now it's easy to hide behind "ambiguous conditions" and claim that your >> system is standard. > > Exactly. You could take (say) three Forth systems, all of which could > exhibit different behaviour under certain conditions, and yet all of > them would be "standard". So, your program *may* work as intended, or > it *may* not. Given that the purpose of the standard is to promote > portability, it's not a very good state of affairs, especially after > some 30 odd years. This doesn't make sense. Either a system conforms to the standard or it doesn't. The guarantee that a standard makes is that if you write conforming programs, then they will work. It also says that if you write for the ambiguities it might not work. > >> Personally I think that ANS was born just to be an umbrella for some forths >> at that time. >> Those forths had a lot of incompatibilities so the ANS was forced >> to "accomodate" these incompatibilities as "ambiguous conditions". > > I agree. And we're still living with the effects. > As someone that does standards for a living (elsewhere, not here) I'm fascinated by the assertion that a standard that doesn't require specific effects on all inputs is considered in some way flawed. If there's one thing that standards folks try not to do, it's bind the hands of implementors or disqualify systems by being over prescriptive. We also try to ensure that users (those the implementors wish to sell to) can take what they have, and with little or no changes, use our systems. An example of that is Hugh's insistence that the control flow stack should be a separate stack. It's explicitly mentioned in the standard that the control flow stack might be the data stack. Generations of Forth programmers have managed to write portable Forth with this ambiguity. Systems can choose to implement the control flow stack in a multiplicity of ways. Yes, sometimes a standard gets it wrong. Then it's up to the standards group *to accomodate existing practise* where possible, and without requiring major re-engineering work. But there has to be evidence that there is a problem caused by the lack of (or incorrect) specification. Why would you want it otherwise?
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-18 02:04 -0700 |
| Message-ID | <c34062d3-181a-44ed-b50f-6466a95435f4@googlegroups.com> |
| In reply to | #39818 |
joi, 18 iunie 2015, 11:27:21 UTC+3, Alex McDonald a scris: > on 18/06/2015 08:15:47, Mark Wills wrote: > > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: > >> And now it's easy to hide behind "ambiguous conditions" and claim that your > >> system is standard. > > > > Exactly. You could take (say) three Forth systems, all of which could > > exhibit different behaviour under certain conditions, and yet all of > > them would be "standard". So, your program *may* work as intended, or > > it *may* not. Given that the purpose of the standard is to promote > > portability, it's not a very good state of affairs, especially after > > some 30 odd years. > > This doesn't make sense. Either a system conforms to the standard or it > doesn't. The guarantee that a standard makes is that if you write > conforming programs, then they will work. It also says that if you write > for the ambiguities it might not work. > If you take out all ambiguities what does remain? How much of it? I said there are TOO MANY ambiguities. > > > >> Personally I think that ANS was born just to be an umbrella for some forths > >> at that time. > >> Those forths had a lot of incompatibilities so the ANS was forced > >> to "accomodate" these incompatibilities as "ambiguous conditions". > > > > I agree. And we're still living with the effects. > > > > As someone that does standards for a living (elsewhere, not here) I'm > fascinated by the assertion that a standard that doesn't require specific > effects on all inputs is considered in some way flawed. If there's one It was about FIND (or tick). There are not too many inputs. In fact there is only one input: the word. Do you find it? Or don't you? The word type or how many types can we have, it's another discussion. > thing that standards folks try not to do, it's bind the hands of > implementors or disqualify systems by being over prescriptive. We also > try to ensure that users (those the implementors wish to sell to) can > take what they have, and with little or no changes, use our systems. > > An example of that is Hugh's insistence that the control flow stack > should be a separate stack. It's explicitly mentioned in the standard > that the control flow stack might be the data stack. Generations of Forth > programmers have managed to write portable Forth with this ambiguity. > Systems can choose to implement the control flow stack in a multiplicity > of ways. > The control stack being data stack is really obsolete. It's so simple to have a separate stack for control flow, even for the most constrained embedded systems! I would see this another way: starting with '90 (for example) the modern forth systems should have been trying to insists on separate control flow stack. Now we would have been able to call this an obsolete feature and take away another "may or may not" from the 20xy standard. > Yes, sometimes a standard gets it wrong. Then it's up to the standards > group *to accomodate existing practise* where possible, and without > requiring major re-engineering work. But there has to be evidence that > there is a problem caused by the lack of (or incorrect) specification. > > Why would you want it otherwise? I would want it said clearly in the next standard (that tick find etc to return an xt) and the "major forth vendors" (including open source ones) to fix their implementation. Is this requiring major re-engineering work? I don't think so.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-06-18 03:32 -0700 |
| Message-ID | <d01576ec-50de-45cb-bcb0-11d45651b477@googlegroups.com> |
| In reply to | #39819 |
On Thursday, 18 June 2015 10:04:44 UTC+1, Raimond Dragomir wrote: > joi, 18 iunie 2015, 11:27:21 UTC+3, Alex McDonald a scris: > > on 18/06/2015 08:15:47, Mark Wills wrote: > > > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: > > >> And now it's easy to hide behind "ambiguous conditions" and claim that your > > >> system is standard. > > > > > > Exactly. You could take (say) three Forth systems, all of which could > > > exhibit different behaviour under certain conditions, and yet all of > > > them would be "standard". So, your program *may* work as intended, or > > > it *may* not. Given that the purpose of the standard is to promote > > > portability, it's not a very good state of affairs, especially after > > > some 30 odd years. > > > > This doesn't make sense. Either a system conforms to the standard or it > > doesn't. The guarantee that a standard makes is that if you write > > conforming programs, then they will work. It also says that if you write > > for the ambiguities it might not work. > > > If you take out all ambiguities what does remain? How much of it? I said there are TOO MANY ambiguities. > > > > > > >> Personally I think that ANS was born just to be an umbrella for some forths > > >> at that time. > > >> Those forths had a lot of incompatibilities so the ANS was forced > > >> to "accomodate" these incompatibilities as "ambiguous conditions". > > > > > > I agree. And we're still living with the effects. > > > > > > > As someone that does standards for a living (elsewhere, not here) I'm > > fascinated by the assertion that a standard that doesn't require specific > > effects on all inputs is considered in some way flawed. If there's one > > It was about FIND (or tick). There are not too many inputs. In fact there is > only one input: the word. Do you find it? Or don't you? The word type or > how many types can we have, it's another discussion. > > > thing that standards folks try not to do, it's bind the hands of > > implementors or disqualify systems by being over prescriptive. We also > > try to ensure that users (those the implementors wish to sell to) can > > take what they have, and with little or no changes, use our systems. > > > > An example of that is Hugh's insistence that the control flow stack > > should be a separate stack. It's explicitly mentioned in the standard > > that the control flow stack might be the data stack. Generations of Forth > > programmers have managed to write portable Forth with this ambiguity. > > Systems can choose to implement the control flow stack in a multiplicity > > of ways. > > > The control stack being data stack is really obsolete. It's so simple to > have a separate stack for control flow, even for the most constrained > embedded systems! I would see this another way: starting with '90 (for > example) the modern forth systems should have been trying to insists on > separate control flow stack. Now we would have been able to call this > an obsolete feature and take away another "may or may not" from the 20xy > standard. > > > Yes, sometimes a standard gets it wrong. Then it's up to the standards > > group *to accomodate existing practise* where possible, and without > > requiring major re-engineering work. But there has to be evidence that > > there is a problem caused by the lack of (or incorrect) specification. > > > > Why would you want it otherwise? > > I would want it said clearly in the next standard (that tick find etc to return > an xt) and the "major forth vendors" (including open source ones) to fix > their implementation. Is this requiring major re-engineering work? I don't > think so. I would like to see much more use of SHALL and much less use of MAY. I hope it doesn't come across as being mean to the people that have toiled over the standard over the years, I fully appreciate that it must be very difficult indeed to satsify everyone. But the only way to make sure programs do run portably is to be more prescriptive and leave less wriggle-room for implementors to be able to argue that their particular interpretation of the standard is correct. This however, would require a change in thinking in terms of what the standard is for, which is perhaps of the crux of my problems with the standard. The standard attempts to look back and encapsulate common practice. Common practice may be disparate. I prefer a standard that looks forward, and attempts to shape common practice in an effort to reduce disparity. I do appreciate that, certainly in the case of programming standards, it would be going against the grain to do that but in terms of reaching an end-goal of portability of software, I remain convinced that that is the best approach to take. With all due respect to those that have worked on the standard over the years. It may even be useful to publish guidance notes. This would not have be a part of the standard text, it could be a separate document that gives guidance or best practices to increase portability. To give an example: The compilation flags being on the data stack. This can be a problem if you want to compile a value from the stack because colon-sys might be in the way. However, a simple change in strategy overcomes that problem. Instead of: some-calculation ( -- n) : some-word [ , ] ... ; The problem is trivially fixed: : some-word [ some-calculation , ] ... ; No change to the standard (in this particular example) would be required as it's trivial to overcome the problem. Published best practice could cover the issue giving the standard some means of defence if challenged on the issue. "Ah! You're not following best practice. Fix your code!" These Portability Guidance Notes could be specified in an appendix of the standard, I suppose, though they would probably be more applicable to programmers than implementors. Regards Mark
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-18 04:19 -0700 |
| Message-ID | <74067cb9-c009-4757-a26a-5005b255fa80@googlegroups.com> |
| In reply to | #39820 |
joi, 18 iunie 2015, 13:32:09 UTC+3, Mark Wills a scris: > On Thursday, 18 June 2015 10:04:44 UTC+1, Raimond Dragomir wrote: > > joi, 18 iunie 2015, 11:27:21 UTC+3, Alex McDonald a scris: > > > on 18/06/2015 08:15:47, Mark Wills wrote: > > > > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: > > > >> And now it's easy to hide behind "ambiguous conditions" and claim that your > > > >> system is standard. > > > > > > > > Exactly. You could take (say) three Forth systems, all of which could > > > > exhibit different behaviour under certain conditions, and yet all of > > > > them would be "standard". So, your program *may* work as intended, or > > > > it *may* not. Given that the purpose of the standard is to promote > > > > portability, it's not a very good state of affairs, especially after > > > > some 30 odd years. > > > > > > This doesn't make sense. Either a system conforms to the standard or it > > > doesn't. The guarantee that a standard makes is that if you write > > > conforming programs, then they will work. It also says that if you write > > > for the ambiguities it might not work. > > > > > If you take out all ambiguities what does remain? How much of it? I said there are TOO MANY ambiguities. > > > > > > > > > >> Personally I think that ANS was born just to be an umbrella for some forths > > > >> at that time. > > > >> Those forths had a lot of incompatibilities so the ANS was forced > > > >> to "accomodate" these incompatibilities as "ambiguous conditions". > > > > > > > > I agree. And we're still living with the effects. > > > > > > > > > > As someone that does standards for a living (elsewhere, not here) I'm > > > fascinated by the assertion that a standard that doesn't require specific > > > effects on all inputs is considered in some way flawed. If there's one > > > > It was about FIND (or tick). There are not too many inputs. In fact there is > > only one input: the word. Do you find it? Or don't you? The word type or > > how many types can we have, it's another discussion. > > > > > thing that standards folks try not to do, it's bind the hands of > > > implementors or disqualify systems by being over prescriptive. We also > > > try to ensure that users (those the implementors wish to sell to) can > > > take what they have, and with little or no changes, use our systems. > > > > > > An example of that is Hugh's insistence that the control flow stack > > > should be a separate stack. It's explicitly mentioned in the standard > > > that the control flow stack might be the data stack. Generations of Forth > > > programmers have managed to write portable Forth with this ambiguity. > > > Systems can choose to implement the control flow stack in a multiplicity > > > of ways. > > > > > The control stack being data stack is really obsolete. It's so simple to > > have a separate stack for control flow, even for the most constrained > > embedded systems! I would see this another way: starting with '90 (for > > example) the modern forth systems should have been trying to insists on > > separate control flow stack. Now we would have been able to call this > > an obsolete feature and take away another "may or may not" from the 20xy > > standard. > > > > > Yes, sometimes a standard gets it wrong. Then it's up to the standards > > > group *to accomodate existing practise* where possible, and without > > > requiring major re-engineering work. But there has to be evidence that > > > there is a problem caused by the lack of (or incorrect) specification. > > > > > > Why would you want it otherwise? > > > > I would want it said clearly in the next standard (that tick find etc to return > > an xt) and the "major forth vendors" (including open source ones) to fix > > their implementation. Is this requiring major re-engineering work? I don't > > think so. > > I would like to see much more use of SHALL and much less use of MAY. > > I hope it doesn't come across as being mean to the people that have > toiled over the standard over the years, I fully appreciate that it > must be very difficult indeed to satsify everyone. But the only way > to make sure programs do run portably is to be more prescriptive > and leave less wriggle-room for implementors to be able to argue > that their particular interpretation of the standard is correct. > This however, would require a change in thinking in terms of what > the standard is for, which is perhaps of the crux of my problems > with the standard. The standard attempts to look back and encapsulate > common practice. Common practice may be disparate. I prefer a > standard that looks forward, and attempts to shape common practice > in an effort to reduce disparity. I do appreciate that, certainly > in the case of programming standards, it would be going against the > grain to do that but in terms of reaching an end-goal of portability > of software, I remain convinced that that is the best approach to > take. With all due respect to those that have worked on the standard > over the years. > I couldn't say it better. A better standard will help forth vendors. For example, a stubborn user (like Hugh) will call VFX support and ask "why cannot I do X in a standard way?" The support team will respond: "But you can do X, it's standard". "No, I can't because I compiled X on another 3 standard forths and behaves differently". Who is wrong here? In fact the question is: Who is the standard helping, the compiler writers or the end user?
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-18 12:31 +0000 |
| Message-ID | <5582b824.639886663@news.eternal-september.org> |
| In reply to | #39822 |
On Thu, 18 Jun 2015 04:19:33 -0700 (PDT), Raimond Dragomir <raimond.dragomir@gmail.com> wrote: >A better standard will help forth vendors. For example, a stubborn user >(like Hugh) will call VFX support and ask "why cannot I do X in a standard >way?" The support team will respond: "But you can do X, it's standard". "No, >I can't because I compiled X on another 3 standard forths and behaves >differently". Who is wrong here? In fact the question is: Who is the standard >helping, the compiler writers or the end user? Being stubborn with support people doesn't help your case if you are also unpleasant. I have done and do tech support and the house rule is that people who are unpleasant are referred to me. A user of technical support has to understand that implementation decisions were made for reasons. Not all of those decisions will be "right" for all users. It is probably true that *any* change to the standard will upset some programmers and/or users. A better question is: What should a new standard say, and how do we get there collaboratively? It can take several years before some questions are even listened to by the Forth community, and another few years before consensus even starts to emerge. That is one reason why most standards change no more frequently than once per decade. 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 | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2015-06-18 05:57 -0700 |
| Message-ID | <c27f16fe-986f-46bc-942a-819d10ea63ca@googlegroups.com> |
| In reply to | #39824 |
joi, 18 iunie 2015, 15:31:48 UTC+3, Stephen Pelc a scris: > On Thu, 18 Jun 2015 04:19:33 -0700 (PDT), Raimond Dragomir > <raimond.dragomir@gmail.com> wrote: > > >A better standard will help forth vendors. For example, a stubborn user > >(like Hugh) will call VFX support and ask "why cannot I do X in a standard > >way?" The support team will respond: "But you can do X, it's standard". "No, > >I can't because I compiled X on another 3 standard forths and behaves > >differently". Who is wrong here? In fact the question is: Who is the standard > >helping, the compiler writers or the end user? > > Being stubborn with support people doesn't help your case if you are > also unpleasant. I have done and do tech support and the house rule is > that people who are unpleasant are referred to me. A user of technical > support has to understand that implementation decisions were made for > reasons. Not all of those decisions will be "right" for all users. It > is probably true that *any* change to the standard will upset some > programmers and/or users. > What would you say to such a user, who wants to write a program that works the same on different standard forths? "Bad luck, that's the standard, you have to live with that"? Or do you help him finding a solution? I didn't ask Hugh if he asked for help and what help did he get in writing his novice package. But he is the only one that I know who wrote such a non-trivial package in truly standard way. He is at least trying. > A better question is: What should a new standard say, and how do > we get there collaboratively? > More "shalls" fewer "mays". Listening to unpleasant people also, maybe they say something usefull. The standard is there for ensuring portability of programs, not for teaching or promoting or whatever else. > It can take several years before some questions are even listened to > by the Forth community, and another few years before consensus even > starts to emerge. That is one reason why most standards change no > more frequently than once per decade. > That's bad. There are already two decades missed. That speaks something about what consensus is there or how the questions are listened in the forth community. > 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-06-18 12:21 +0000 |
| Message-ID | <5582b0a3.637965683@news.eternal-september.org> |
| In reply to | #39820 |
On Thu, 18 Jun 2015 03:32:07 -0700 (PDT), Mark Wills <markwills1970@gmail.com> wrote: >The standard attempts to look back and encapsulate >common practice. Common practice may be disparate. I prefer a >standard that looks forward, and attempts to shape common practice >in an effort to reduce disparity. I do appreciate that, certainly >in the case of programming standards, it would be going against the >grain to do that but in terms of reaching an end-goal of portability >of software, I remain convinced that that is the best approach to >take. With all due respect to those that have worked on the standard >over the years. The problem is that most of the problems have arisen where ANS attempted to look forward or to be kind to others. The whole tick issue comes from a concession to cmForth which used two wordlists, one being used during compilation. POSTPONE was another entry whose ripple effects have taken many years to die away. A big mistake is to underestimate the ingenuity of Forth programmers. This causes huge problems after Bernd discovers a useful side-effect that was not intended or spotted by the authors of proposals. That's why common practice is so important. Another mistake is to forget that systems are written by people and that they often have an emotional investment in their systems. >It may even be useful to publish guidance notes. This would not have >be a part of the standard text, it could be a separate document >that gives guidance or best practices to increase portability. And who is going to do it? I tink that you have just volunteered! All of us who attend standards meetings do it in our own time and on our own dollar/euro/pound/rand/rouble. >To give an example: The compilation flags being on the data stack. >This can be a problem if you want to compile a value from the >stack because colon-sys might be in the way. However, a simple >change in strategy overcomes that problem. Instead of: > >some-calculation ( -- n) >: some-word [ , ] ... ; > >The problem is trivially fixed: >: some-word [ some-calculation , ] ... ; Yebbut, you do not consider the case of native code compilation: : some-word [ some-calculation ] literal ... ; or repeated usage : some-word2 [ some-calculation 2* ] literal ... ; : some-word3 [ some-calculation 3* ] literal ... ; ... Being a coordinator of "best practice" isn't easy. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2015-06-18 08:01 -1000 |
| Message-ID | <K96dncKVf40emh7InZ2dnUU7-VWdnZ2d@supernews.com> |
| In reply to | #39823 |
On 6/18/15 2:21 AM, Stephen Pelc wrote: > On Thu, 18 Jun 2015 03:32:07 -0700 (PDT), Mark Wills > <markwills1970@gmail.com> wrote: > >> The standard attempts to look back and encapsulate >> common practice. Common practice may be disparate. I prefer a >> standard that looks forward, and attempts to shape common practice >> in an effort to reduce disparity. I do appreciate that, certainly >> in the case of programming standards, it would be going against the >> grain to do that but in terms of reaching an end-goal of portability >> of software, I remain convinced that that is the best approach to >> take. With all due respect to those that have worked on the standard >> over the years. > > The problem is that most of the problems have arisen where ANS > attempted to look forward or to be kind to others. The whole tick > issue comes from a concession to cmForth which used two wordlists, one > being used during compilation. > > POSTPONE was another entry whose ripple effects have taken many years > to die away. In the late 80's and early 90's, when the ANS Forth TC was hard at work, ANSI sent us via snail mail all the correspondence for other language groups then active. Volumes of paper. FORTRAN, COBOL, and C were all active. When the new FORTRAN standard was put out for public review, the howls were unbelievable. When COBOL was published, several multi-million dollar law suits were filed. In the aftermath of the new C, Stephen told me that he still needed 5 different C compilers to maintain the interfaces to things for his customers. The notion that a language standard, either forward- or backward-looking will create effortless portability is a fantasy. In fact, in the aftermath of the publication of ANS Forth virtually all implementers of widely-used Forths (both commercial and free) released compliant systems within a few years, and it became much, much easier for Forth programmers to work on different systems. > A big mistake is to underestimate the ingenuity of Forth programmers. > This causes huge problems after Bernd discovers a useful side-effect > that was not intended or spotted by the authors of proposals. That's > why common practice is so important. > > Another mistake is to forget that systems are written by people and > that they often have an emotional investment in their systems. > >> It may even be useful to publish guidance notes. This would not have >> be a part of the standard text, it could be a separate document >> that gives guidance or best practices to increase portability. > > And who is going to do it? I tink that you have just volunteered! The appendices of the standards attempt to do some of this, and system documentation should help people writing applications for that system. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-18 12:11 -0700 |
| Message-ID | <9c00209a-a211-45ce-91ff-aebad30a9c0d@googlegroups.com> |
| In reply to | #39834 |
On Thursday, June 18, 2015 at 11:01:41 AM UTC-7, Elizabeth D. Rather wrote: > On 6/18/15 2:21 AM, Stephen Pelc wrote: > > On Thu, 18 Jun 2015 03:32:07 -0700 (PDT), Mark Wills > > <markwills1970@gmail.com> wrote: > > > >> The standard attempts to look back and encapsulate > >> common practice. Common practice may be disparate. I prefer a > >> standard that looks forward, and attempts to shape common practice > >> in an effort to reduce disparity. I do appreciate that, certainly > >> in the case of programming standards, it would be going against the > >> grain to do that but in terms of reaching an end-goal of portability > >> of software, I remain convinced that that is the best approach to > >> take. With all due respect to those that have worked on the standard > >> over the years. > > > > The problem is that most of the problems have arisen where ANS > > attempted to look forward or to be kind to others. The whole tick > > issue comes from a concession to cmForth which used two wordlists, one > > being used during compilation. Allowing cmForth under the ANS-Forth umbrella is an example of looking forward??? Most likely, Charles Moore didn't ask for cmForth to be ANS-Forth compliant and was more surprised than anybody else when his goofy idea became standard. > In the late 80's and early 90's, when the ANS Forth TC was hard at work, > ANSI sent us via snail mail all the correspondence for other language > groups then active. Volumes of paper. FORTRAN, COBOL, and C were all > active. When the new FORTRAN standard was put out for public review, the > howls were unbelievable. When COBOL was published, several multi-million > dollar law suits were filed. In the aftermath of the new C, Stephen told > me that he still needed 5 different C compilers to maintain the > interfaces to things for his customers. The notion that a language > standard, either forward- or backward-looking will create effortless > portability is a fantasy. COBOL and Fortran aren't good models to learn from, because they are both failures --- this was old news in 1994. The C standard actually worked pretty well. Stephen Pelc is quoted as saying that he "needed 5 different C compilers to maintain the interfaces to things for his customers" --- this is most likely because those interfaces were written in assembly-language and the "things" being interfaced to were highly hardware-dependent --- a language standard isn't intended to make I/O portable, so this isn't really an indictment of the C standard. > In fact, in the aftermath of the publication of ANS Forth virtually all > implementers of widely-used Forths (both commercial and free) released > compliant systems within a few years, and it became much, much easier > for Forth programmers to work on different systems. The ANS-Forth standard was submitted to ANSI, without ever being tested. The ANS-Forth committee's idea of being "hard at work" didn't include writing a reference compiler for ANS-Forth and using it to test ANS-Forth's usability. If a reference compiler had been available, most of these problems would have become apparent BEFORE the ANS-Forth document was written in stone, rather than after. The ANS-Forth committee's idea of being "hard at work" primarily involved chest-thumping and hot-air blowing. ANS-Forth was just a marketing gimmick from Elizabeth Rather intended to prove to the world that Forth Inc. sets the standard for the entire Forth community and that plebians such as myself depend entirely on Forth Inc. --- she was in a hurry to submit ANS-Forth to ANSI and have it written in stone, so she could begin the self-congratulation part of the project as soon as possible (the self-congratulation part has continued for 20+ years now and shows no signs of slowing down). Also, in the early 1990s the only professional Forth system available was UR/Forth from Laboratory Microsystems (LMI) --- it was not rewritten to be compliant with ANS-Forth --- Ray Duncan just gave up on Forth and folded up LMI rather than accept ANS-Forth. In the "aftermath of the publication of ANS Forth" virtually all Forth programmers abandoned Forth like rats fleeing from a sinking ship. > >> It may even be useful to publish guidance notes. This would not have > >> be a part of the standard text, it could be a separate document > >> that gives guidance or best practices to increase portability. > > > > And who is going to do it? I tink that you have just volunteered! > > The appendices of the standards attempt to do some of this, and system > documentation should help people writing applications for that system. With all due respect to brave Mark Wills, this talk about "guidance notes" for ANS-Forth is foolishness --- when the ANS-Forth document declares almost every aspect of the language to be ambiguous, then there is no way out of the woods and guidance won't help. The ANS-Forth standard just has to be phased out and replaced with a new standard based on thinking and testing rather than speculating and pontificating. We can have two incompatible standards for a period of time --- ANS-Forth and the new standard ---the people who care about ANS-Forth (mostly Forth Inc.) can continue to struggle with it, but will do so by themselves in a small sound-proof room so as to not make such a public nuisance of themselves --- the more forward-thinking Forth programmers will work on the new standard in public. Some Forth compiler-vendors (MPE) will have to support two incompatible compilers for a while, but they will eventually drop ANS-Forth support because it is expensive and there aren't any customers remaining who want it. ANS-Forth confuses the heck out of the users, and they call the compiler-vendor's help-line to complain, whereas the users of a standard that makes sense will be less confused and will make fewer calls to the help-line ---so, ultimately the new standard will reduce help-line cost for the compiler vendors, increase the number of happy customers, and generally make everybody's life easier. ANS-Forth has nothing of value to contribute to the Forth community.
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-06-18 17:25 -0400 |
| Message-ID | <mlvcvm$kg7$1@speranza.aioe.org> |
| In reply to | #39835 |
On 18/06/2015 3:11 PM, hughaguilar96@gmail.com wrote: > On Thursday, June 18, 2015 at 11:01:41 AM UTC-7, Elizabeth D. Rather wrote: >> In the late 80's and early 90's, when the ANS Forth TC was hard at work, >> ANSI sent us via snail mail all the correspondence for other language >> groups then active. Volumes of paper. FORTRAN, COBOL, and C were all >> active. When the new FORTRAN standard was put out for public review, the >> howls were unbelievable. When COBOL was published, several multi-million >> dollar law suits were filed. In the aftermath of the new C, Stephen told >> me that he still needed 5 different C compilers to maintain the >> interfaces to things for his customers. The notion that a language >> standard, either forward- or backward-looking will create effortless >> portability is a fantasy. > > COBOL and Fortran aren't good models to learn from, because they are both > failures --- this was old news in 1994. > > The C standard actually worked pretty well. It has many of the same issues that is being expressed here for forth standardization. I worked on ISO/WG14 C represented by ANSI from the US. I know the effort and issues it takes to do standardization. It requires an lot of co-operation and compromise by those practiced in the field. > Stephen Pelc is quoted as saying > that he "needed 5 different C compilers to maintain the interfaces to things > for his customers" --- this is most likely because those interfaces were > written in assembly-language and the "things" being interfaced to were highly > hardware-dependent --- a language standard isn't intended to make I/O portable, > so this isn't really an indictment of the C standard. Shooting down a strawman is so much easier than dealing with facts. About I/O standardization in C you might want to read ISO/IEC 18037 and some of the proceedings papers that led up to it and other embedded C standards. Most C compilers for embedded systems created in the last two or three decades do not need assembly code ever in applications. > >> In fact, in the aftermath of the publication of ANS Forth virtually all >> implementers of widely-used Forths (both commercial and free) released >> compliant systems within a few years, and it became much, much easier >> for Forth programmers to work on different systems. > > The ANS-Forth standard was submitted to ANSI, without ever being tested. > The ANS-Forth committee's idea of being "hard at work" didn't include > writing a reference compiler for ANS-Forth and using it to test ANS-Forth's > usability. If a reference compiler had been available, most of these problems > would have become apparent BEFORE the ANS-Forth document was written in > stone, rather than after. Standards as you have been told many times codify existing practice and isn't a design specification to create a standard product. There is a big difference. > > The ANS-Forth committee's idea of being "hard at work" primarily involved > chest-thumping and hot-air blowing. ANS-Forth was just a marketing gimmick > from Elizabeth Rather intended to prove to the world that Forth Inc. sets > the standard for the entire Forth community and that plebians such as > myself depend entirely on Forth Inc. --- she was in a hurry to submit > ANS-Forth to ANSI and have it written in stone, so she could begin the > self-congratulation part of the project as soon as possible (the > self-congratulation part has continued for 20+ years now and shows no > signs of slowing down). > > Also, in the early 1990s the only professional Forth system available > was UR/Forth from Laboratory Microsystems (LMI) --- it was not rewritten > to be compliant with ANS-Forth --- Ray Duncan just gave up on Forth and > folded up LMI rather than accept ANS-Forth. In the "aftermath of the > publication of ANS Forth" virtually all Forth programmers abandoned > Forth like rats fleeing from a sinking ship. It is a standard not a set of laws. Write a set of tools and proclaim them to be "NOT" ANS-forth compatible and harvest all the fleeing customers. It what you say is true 20 years on it would be a non issue. It wouldn't exist. > >>>> It may even be useful to publish guidance notes. This would not have >>>> be a part of the standard text, it could be a separate document >>>> that gives guidance or best practices to increase portability. >>> >>> And who is going to do it? I think that you have just volunteered! >> >> The appendices of the standards attempt to do some of this, and system >> documentation should help people writing applications for that system. > > With all due respect to brave Mark Wills, this talk about "guidance > notes" for ANS-Forth is foolishness --- when the ANS-Forth document > declares almost every aspect of the language to be ambiguous, then > there is no way out of the woods and guidance won't help. This is one major issue facing all standards groups with forth even more so with an incredibly flexible underlying language. What should be done with differences in implementation due to underlying hardware architecture or language implementation features. A standards group can do one of a few things. Make the conflict implementation defined or force a single definition so all new implementations will conform. The later is the obvious choice but not the workable one. The conforming option breaks a lot of working code losing an even greater amount of work. The conforming option singles out hardware for which there is becomes no workable solution. Every group I have been a part of has wrestled with this and come to the same solution. Some things just need to be left implementation defined > > The ANS-Forth standard just has to be phased out and replaced with > a new standard based on thinking and testing rather than speculating > and pontificating. This sounds like a new language design. It is rare that a language can be designed and then have multiple compatible implementations that are commercially useful. The only one I can quickly think of is ADA but I am sure there are others. The next question is who should do the work to create this design. Finally the cost of creating new tools and conformance tests are formidable. It is easy to say what should be done as a critic much more difficult to be part of the process. > We can have two incompatible standards for a > period of time --- ANS-Forth and the new standard ---the people > who care about ANS-Forth (mostly Forth Inc.) can continue to struggle > with it, but will do so by themselves in a small sound-proof room > so as to not make such a public nuisance of themselves --- the more > forward-thinking Forth programmers will work on the new standard in > public. Some Forth compiler-vendors (MPE) will have to support two > incompatible compilers for a while, but they will eventually drop > ANS-Forth support because it is expensive and there aren't any > customers remaining who want it. ANS-Forth confuses the heck out > of the users, and they call the compiler-vendor's help-line to > complain, whereas the users of a standard that makes sense will > be less confused and will make fewer calls to the help-line ---so, > ultimately the new standard will reduce help-line cost for the > compiler vendors, increase the number of happy customers, and > generally make everybody's life easier. The two copy problem would likely kill both languages. Having the same customer base and doubling the support cost and capital expenditure would make the two copy phase one out approach un-workable. > > ANS-Forth has nothing of value to contribute to the Forth community. > If nothing else it provides focus on the language issues. Write you own language implementation, un-ambiguously document it and find a customer base who are willing to use it. The doing part is much harder that the criticizing part. w..
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-06-18 22:56 +0200 |
| Message-ID | <mlvb7b$och$1@dont-email.me> |
| In reply to | #39823 |
Stephen Pelc wrote: > A big mistake is to underestimate the ingenuity of Forth programmers. > This causes huge problems after Bernd discovers a useful side-effect > that was not intended or spotted by the authors of proposals. That's > why common practice is so important. Having building blocks which can be combined in many ways is one of the strength of Forth. Therefore, such surprises are going to happen. > Another mistake is to forget that systems are written by people and > that they often have an emotional investment in their systems. Which is why your minimal-ego statement for writing portable programs is also true for writing systems that are easy to port to. A permissive standard allows many Forth systems to be labeled "standard", a restrictive standard allows many Forth programs to be labeled "portable". But a restrictive standard will make it difficult to make experiments, so we have to find the right balance. -- 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 | coos <chforth@hccnet.nl> |
|---|---|
| Date | 2015-06-18 18:54 +0200 |
| Message-ID | <d71eewia7rrx.1bumh93uwkinw.dlg@40tude.net> |
| In reply to | #39820 |
Op Thu, 18 Jun 2015 03:32:07 -0700 (PDT) schreef Mark Wills: > On Thursday, 18 June 2015 10:04:44 UTC+1, Raimond Dragomir wrote: >> joi, 18 iunie 2015, 11:27:21 UTC+3, Alex McDonald a scris: >>> on 18/06/2015 08:15:47, Mark Wills wrote: >>> > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: >>> >> And now it's easy to hide behind "ambiguous conditions" and claim that your >>> >> system is standard. >>> > >>> > Exactly. You could take (say) three Forth systems, all of which could >>> > exhibit different behaviour under certain conditions, and yet all of >>> > them would be "standard". So, your program *may* work as intended, or >>> > it *may* not. Given that the purpose of the standard is to promote >>> > portability, it's not a very good state of affairs, especially after >>> > some 30 odd years. >>> >>> This doesn't make sense. Either a system conforms to the standard or it >>> doesn't. The guarantee that a standard makes is that if you write >>> conforming programs, then they will work. It also says that if you write >>> for the ambiguities it might not work. >>> >> If you take out all ambiguities what does remain? How much of it? I said there are TOO MANY ambiguities. >> >>> > >>> >> Personally I think that ANS was born just to be an umbrella for some forths >>> >> at that time. >>> >> Those forths had a lot of incompatibilities so the ANS was forced >>> >> to "accomodate" these incompatibilities as "ambiguous conditions". >>> > >>> > I agree. And we're still living with the effects. >>> > >>> >>> As someone that does standards for a living (elsewhere, not here) I'm >>> fascinated by the assertion that a standard that doesn't require specific >>> effects on all inputs is considered in some way flawed. If there's one >> >> It was about FIND (or tick). There are not too many inputs. In fact there is >> only one input: the word. Do you find it? Or don't you? The word type or >> how many types can we have, it's another discussion. >> >>> thing that standards folks try not to do, it's bind the hands of >>> implementors or disqualify systems by being over prescriptive. We also >>> try to ensure that users (those the implementors wish to sell to) can >>> take what they have, and with little or no changes, use our systems. >>> >>> An example of that is Hugh's insistence that the control flow stack >>> should be a separate stack. It's explicitly mentioned in the standard >>> that the control flow stack might be the data stack. Generations of Forth >>> programmers have managed to write portable Forth with this ambiguity. >>> Systems can choose to implement the control flow stack in a multiplicity >>> of ways. >>> >> The control stack being data stack is really obsolete. It's so simple to >> have a separate stack for control flow, even for the most constrained >> embedded systems! I would see this another way: starting with '90 (for >> example) the modern forth systems should have been trying to insists on >> separate control flow stack. Now we would have been able to call this >> an obsolete feature and take away another "may or may not" from the 20xy >> standard. >> >>> Yes, sometimes a standard gets it wrong. Then it's up to the standards >>> group *to accomodate existing practise* where possible, and without >>> requiring major re-engineering work. But there has to be evidence that >>> there is a problem caused by the lack of (or incorrect) specification. >>> >>> Why would you want it otherwise? >> >> I would want it said clearly in the next standard (that tick find etc to return >> an xt) and the "major forth vendors" (including open source ones) to fix >> their implementation. Is this requiring major re-engineering work? I don't >> think so. > > I would like to see much more use of SHALL and much less use of MAY. > > I hope it doesn't come across as being mean to the people that have > toiled over the standard over the years, I fully appreciate that it > must be very difficult indeed to satsify everyone. But the only way > to make sure programs do run portably is to be more prescriptive > and leave less wriggle-room for implementors to be able to argue > that their particular interpretation of the standard is correct. > This however, would require a change in thinking in terms of what > the standard is for, which is perhaps of the crux of my problems > with the standard. The standard attempts to look back and encapsulate > common practice. Common practice may be disparate. I prefer a > standard that looks forward, and attempts to shape common practice > in an effort to reduce disparity. I do appreciate that, certainly > in the case of programming standards, it would be going against the > grain to do that but in terms of reaching an end-goal of portability > of software, I remain convinced that that is the best approach to > take. With all due respect to those that have worked on the standard > over the years. > > It may even be useful to publish guidance notes. This would not have > be a part of the standard text, it could be a separate document > that gives guidance or best practices to increase portability. > > To give an example: The compilation flags being on the data stack. > This can be a problem if you want to compile a value from the > stack because colon-sys might be in the way. However, a simple > change in strategy overcomes that problem. Instead of: > > some-calculation ( -- n) >: some-word [ , ] ... ; > > The problem is trivially fixed: >: some-word [ some-calculation , ] ... ; This is not a trivial matter. , (comma) is used for storing something in data space. Storing into code space (body of a colon definition is done with COMPILE, or LITERAL (see the message of Stephen Pelc). There are implementations that share code space with data space, but it is legal to separate the two, even the old pre-ans F-PC did this. groet, Coos
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-06-18 10:53 -0700 |
| Message-ID | <c899fd21-f90c-4cb4-805c-a8b7f187f0f9@googlegroups.com> |
| In reply to | #39819 |
On Thursday, June 18, 2015 at 2:04:44 AM UTC-7, Raimond Dragomir wrote: > joi, 18 iunie 2015, 11:27:21 UTC+3, Alex McDonald a scris: > > on 18/06/2015 08:15:47, Mark Wills wrote: > > > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: > > >> And now it's easy to hide behind "ambiguous conditions" and claim that your > > >> system is standard. > > > > > > Exactly. You could take (say) three Forth systems, all of which could > > > exhibit different behaviour under certain conditions, and yet all of > > > them would be "standard". So, your program *may* work as intended, or > > > it *may* not. Given that the purpose of the standard is to promote > > > portability, it's not a very good state of affairs, especially after > > > some 30 odd years. > > > > This doesn't make sense. Either a system conforms to the standard or it > > doesn't. The guarantee that a standard makes is that if you write > > conforming programs, then they will work. It also says that if you write > > for the ambiguities it might not work. > > > If you take out all ambiguities what does remain? How much of it? I said there are TOO MANY ambiguities. Here is a motto for the ANS-Forth promoters to use: "With ANS-Forth, anything is possible!"
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-06-18 21:31 +0100 |
| Message-ID | <mlv9ns$ij7$1@dont-email.me> |
| In reply to | #39819 |
on 18/06/2015 10:04:39, Raimond Dragomir wrote: > joi, 18 iunie 2015, 11:27:21 UTC+3, Alex McDonald a scris: >> on 18/06/2015 08:15:47, Mark Wills wrote: >> > On Thursday, 18 June 2015 07:44:52 UTC+1, Raimond Dragomir wrote: >> >> And now it's easy to hide behind "ambiguous conditions" and claim that your >> >> system is standard. >> > >> > Exactly. You could take (say) three Forth systems, all of which could >> > exhibit different behaviour under certain conditions, and yet all of >> > them would be "standard". So, your program *may* work as intended, or >> > it *may* not. Given that the purpose of the standard is to promote >> > portability, it's not a very good state of affairs, especially after >> > some 30 odd years. >> >> This doesn't make sense. Either a system conforms to the standard or it >> doesn't. The guarantee that a standard makes is that if you write >> conforming programs, then they will work. It also says that if you write >> for the ambiguities it might not work. >> > If you take out all ambiguities what does remain? How much of it? I > said there are TOO MANY ambiguities. Section "4.1.2 Ambiguous conditions" covers them all. Which ones would you make unambiguous? > >> > >> >> Personally I think that ANS was born just to be an umbrella for some forths >> >> at that time. >> >> Those forths had a lot of incompatibilities so the ANS was forced >> >> to "accomodate" these incompatibilities as "ambiguous conditions". >> > >> > I agree. And we're still living with the effects. >> > >> >> As someone that does standards for a living (elsewhere, not here) I'm >> fascinated by the assertion that a standard that doesn't require specific >> effects on all inputs is considered in some way flawed. If there's one > > It was about FIND (or tick). There are not too many inputs. In fact > there is only one input: the word. Do you find it? Or don't you? The > word type or how many types can we have, it's another discussion. Let's have that discussion. We have positive integers, unsigned numbers, negative numbers, zero and so on. There are limits to numbers; varying cells sizes make max and mins vary from system to system. 123456789 123456789 * is a valid number, but it is far too large for my system to represent accurately. Numbers have ambiguities. The same is true of words. There are groups of words, and one of them -- those with no interpretation semantics -- results in an ambiguous condition and it's up to each system what to do. > >> thing that standards folks try not to do, it's bind the hands of >> implementors or disqualify systems by being over prescriptive. We also >> try to ensure that users (those the implementors wish to sell to) can >> take what they have, and with little or no changes, use our systems. >> >> An example of that is Hugh's insistence that the control flow stack >> should be a separate stack. It's explicitly mentioned in the standard >> that the control flow stack might be the data stack. Generations of Forth >> programmers have managed to write portable Forth with this ambiguity. >> Systems can choose to implement the control flow stack in a multiplicity >> of ways. >> > The control stack being data stack is really obsolete. It's so simple > to have a separate stack for control flow, even for the most > constrained embedded systems! I would see this another way: starting > with '90 (for example) the modern forth systems should have been > trying to insists on separate control flow stack. Now we would have > been able to call this an obsolete feature and take away another "may > or may not" from the 20xy standard. At compile time we would require 3 stacks. Why is this needed? > >> Yes, sometimes a standard gets it wrong. Then it's up to the standards >> group *to accomodate existing practise* where possible, and without >> requiring major re-engineering work. But there has to be evidence that >> there is a problem caused by the lack of (or incorrect) specification. >> >> Why would you want it otherwise? > > I would want it said clearly in the next standard (that tick find etc > to return an xt) and the "major forth vendors" (including open source > ones) to fix their implementation. Is this requiring major > re-engineering work? I don't think so. > What would you do with this conformity? In particular, what would you have ' IF do when executed? >
[toc] | [prev] | [next] | [standalone]
Page 4 of 17 — ← Prev page 1 2 3 [4] 5 6 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web