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 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-04-25 01:21 +0200 |
| Message-ID | <mhej4f$mkg$1@dont-email.me> |
| In reply to | #38559 |
Anton Ertl wrote: >>IIRC, the result of our last discussion was that this equivalence doesn't >>hold for compile-only words, because you aren't allowed to tick them. As >>you derive this equivalence from ' foo execute = interpretation semantics. >>If you can't tick foo in a standard way, ' foo execute = undefined; and >>that certainly beaks the compile, equivalence, too. > > Sure, if you like languages with undefined behaviour, one can argue > that way. I'm against languages with undefined behavior, but the defined behavior should actually be reasonable and corresponding to major implementations. The way the current standard specifies compilation and interpretation, with all the consequences for FIND (may be state smart), COMPILE, and others, represents competing implementation practices from 1994, including cmForth, and does not provide a standard solution to words like S" (apart from state- smart). > OTOH, if you look at how COMPILE, is used, there are two ways to use > it: > > 1) Use it in text interpreters. > > 2) Use it to append the same semantics to a definition that EXECUTE > executes. > > Both uses occur in programs that are out there, so we should implement > our systems such that they both work. Yes, as long as there aren't conflicts with exiting usage. ' S" COMPILE, results in various different behaviours depending on the implementation of S". This is not hypothetically undefined, this is currently non-portable. The three major implementers of the Forth 2012 committee have three different ways to implement S": SwiftForth has it state-smart, VFX has it with a smart COMPILE, and Gforth uses a dual-xt approach. > One may argue that not all xts tend to be used with use 2 (also with > use 1, BTW; consider xts coming from :NONAME words), so it's good > enough if these xts don't behave in a way compatible with use 2. In > particular, as I mentioned above, the (single) xt of S" in VFX does > not work properly with use 2. The single xt of S" in Swiftforth doesn't, either, but for different reasons (it's a STATE-smart word). IMHO your example is a straw man right now, because there's no consensus how to implement these words, and therefore, any program making assumptions about these words is right now really non- portable. Not just potentially non-portable when someone starts writing a compiler with the intention to break such a program. It doesn't work right now, and if we want to reduce that portability issue (I think the problems with these words are a portability issue), we can only do so by tightening up the spec. And this will break at least the behavior of two out of three current implementation choices (supposing we will choose one of the existing solutions). So far, all three existing approaches face critics: 1. STATE-smart has been vocally critisized by you 2. smart COMPILE, has been critisized by you 3. dual-xt has been critisized by Stephen Pelc, because it breaks the conceptual unit of name and xt (where the xt is just a token for the name) E.g ' S" >NAME .NAME works fine and as expected in VFX and SwiftForth, while Gforth has no displayable name both for ' S" and COMP' S" DROP. > One may consider that good enough as long as nobody uses it, so no > customer complains, but one should be aware that it is a good-enough > solution, not the right thing (and good-enough more in the Washington > (Redmond) style, not as in the New Jersey (Murray Hill) style that > Gabriel's paper compared the MIT approach to). If we do "the right thing", from the currently three different approaches at words with special compiliation semantics, at most one can survive. I.e. we have the choice to keep things undefined, so that people's non-portable programs continue to work on their platform, or we potentially break some code. There's no wash me but don't get me wet here. We also can't just create a new word for the smart COMPILE,, because that one would break existing code, too. > Anyway, just because no customer has complained to Stephen Pelc yet > does not mean that there is no code out there that uses COMPILE, in > use pattern 2, with an xt where VFX breaks the pattern. Nobody > complained to Stephen Pelc about VFX breaking return-address > manipulations until you came along. Maybe. You had raised some theoretical concerns about his source inliner. The inliner broke hard, and that was completely different from what your concerns were. The smart COMPILE, did not cause any problems with my code, even though I'm exactly doing this case 2) thing, which is the case where your concerns are really really big. And I'm not the only one; IIRC, MPE maintains 5 different OOP packages (much to their dismay), all with the same potential issue. >>> This equivalence is used in, e.g., various OOF packages (dynamic >>> binding EXECUTEs, early binding COMPILE,s), but fortunately you don't >>> use the xt of S" etc. in that context, and ticking S" is rare in >>> general, so the problem does not occur in practice for now. >> >>And we have managed to make sure the problem can't occur in a standard >>program for the Forth-2012 standard. By making all those words that won't >>hold that equivalence untickable. As I'm fully for tightening up the >>spec, we can tighten it up differently. > > Tightening it up in a way that would destandardize the existing uses > is a no-go. Well, the actual really existing use, destandardizing straw men is completely ok. I don't want to break real existing code. > I also don't see a good way to tighten it up in a way that would allow > VFXs current implementation. We already concluded that VFXs current implementation is standard, so it's allowed - if you have problems remembering, I still have the recordings. The question whether we tighten it towards this approach therefore is not to allow it, but if consensus emerges. One vote against would still be a rough consensus. >>Usually, thise OOF package use :NONAME xts for method implementations, and >>:NONAME-xts work. People who use SET-COMPILER on their xts create non- >>standard programs, and they probably know what they do (different >>early/late binding behavior could sometimes be deliberate). > > Deliberate mistakes, like STATE-smart words. Looks cute at first, and > the problems are only seen far later, perhaps by someone else. Forth is not a nanny language. There are features which can cause problems if not used right. There are, on the other hand, features like STATE+IMMEDIATE, which are problematic. > So it seems that you suggest that SET-COMPILER and the like will never > be standardized. Fine with me. I don't suggest this. The question of SET-COMPILER is about emerging consensus. At the moment, we only have a very inadequate standard mean for users to write their own words with special compilation semantics, and that one must go. I won't support dual-xt. That was an implementation option in ANS Forth for cmForth, and because it didn't receive enough review, you figured out that it is the only way to implement these words in ANS Forth. We did that review with Forth-2012, and it's no longer true, in Forth-2012, all three current practice implementations (STATE-smart, dual-xt, SET-COMPILER) are legal; and that was the original intention for ANS Forth, too. If a consensus emerges, we can narrow that down to one option. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-04-25 16:49 +0000 |
| Message-ID | <2015Apr25.184929@mips.complang.tuwien.ac.at> |
| In reply to | #38586 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> OTOH, if you look at how COMPILE, is used, there are two ways to use
>> it:
>>
>> 1) Use it in text interpreters.
>>
>> 2) Use it to append the same semantics to a definition that EXECUTE
>> executes.
>>
>> Both uses occur in programs that are out there, so we should implement
>> our systems such that they both work.
>
>Yes, as long as there aren't conflicts with exiting usage. ' S" COMPILE,
>results in various different behaviours depending on the implementation of
>S". This is not hypothetically undefined, this is currently non-portable.
>The three major implementers of the Forth 2012 committee have three
>different ways to implement S": SwiftForth has it state-smart, VFX has it
>with a smart COMPILE, and Gforth uses a dual-xt approach.
If you want to tighten the standard to allow ' S", SwiftForth and VFX
do it wrongly.
>> One may argue that not all xts tend to be used with use 2 (also with
>> use 1, BTW; consider xts coming from :NONAME words), so it's good
>> enough if these xts don't behave in a way compatible with use 2. In
>> particular, as I mentioned above, the (single) xt of S" in VFX does
>> not work properly with use 2.
>
>The single xt of S" in Swiftforth doesn't, either, but for different reasons
>(it's a STATE-smart word).
COMPILE, certainly works right on SwiftForth. STATE-smartness causes
problems later, however.
>IMHO your example is a straw man right now,
>because there's no consensus how to implement these words, and therefore,
>any program making assumptions about these words is right now really non-
>portable. Not just potentially non-portable when someone starts writing a
>compiler with the intention to break such a program.
So systems have bugs. We papered over these bugs by making ' S" etc.
non-standard, and we can leave it at that. But somebody asked for a
discussion. If you want to tighten the standard and want to allow ' S"
in standard programs, the result should work in the use 2 of COMPILE,.
>3. dual-xt has been critisized by Stephen Pelc, because it breaks the
>conceptual unit of name and xt (where the xt is just a token for the name)
There is no such unity in the standard, as evidenced by the definition
of FIND. One may find having several xts inelegant, but as long as we
have words like S", it's the way to go.
>E.g ' S" >NAME .NAME works fine and as expected in VFX and SwiftForth, while
>Gforth has no displayable name both for ' S" and COMP' S" DROP.
That is easy to fix.
>If we do "the right thing", from the currently three different approaches at
>words with special compiliation semantics, at most one can survive. I.e. we
>have the choice to keep things undefined, so that people's non-portable
>programs continue to work on their platform, or we potentially break some
>code. There's no wash me but don't get me wet here. We also can't just
>create a new word for the smart COMPILE,, because that one would break
>existing code, too.
Wasn't it you who claimed that nobody uses ' S" etc., so not doing the
right thing for ' S" etc. is ok? If you are right, no code will
break.
>The smart COMPILE, did not cause any problems with my code, even though I'm
>exactly doing this case 2) thing, which is the case where your concerns are
>really really big.
Well, STATE-smartness also did not cause problems for you, so it's not
like you detect all problems. But yes, as long as it's limited to the
standard words, I don't expect problems.
>> Tightening it up in a way that would destandardize the existing uses
>> is a no-go.
>
>Well, the actual really existing use, destandardizing straw men is
>completely ok.
We also have to take the conceptual burden on the programmers into
account. If you "tighten" the xt, EXECUTE and COMPILE, such that use
2 works for some xts, but not for others (and probably without a test
whether an xt belongs to the use-2 class or not), the standard becomes
messy.
May be a better tightening idea is to require ' S" etc. to produce an
error, in preparation for phasing S" etc. out. I have no good idea
how to tighten FIND, though.
>> I also don't see a good way to tighten it up in a way that would allow
>> VFXs current implementation.
>
>We already concluded that VFXs current implementation is standard, so it's
>allowed - if you have problems remembering, I still have the recordings.
>The question whether we tighten it towards this approach therefore is not to
>allow it, but if consensus emerges.
Tightening towards VFX's current implementation is not a good way to
tighten the standard, as it outlaws use 2.
>>>Usually, thise OOF package use :NONAME xts for method implementations, and
>>>:NONAME-xts work. People who use SET-COMPILER on their xts create non-
>>>standard programs, and they probably know what they do (different
>>>early/late binding behavior could sometimes be deliberate).
>>
>> Deliberate mistakes, like STATE-smart words. Looks cute at first, and
>> the problems are only seen far later, perhaps by someone else.
>
>Forth is not a nanny language. There are features which can cause problems
>if not used right. There are, on the other hand, features like
>STATE+IMMEDIATE, which are problematic.
As are different early/late binding semantics.
>> So it seems that you suggest that SET-COMPILER and the like will never
>> be standardized. Fine with me.
>
>I don't suggest this. The question of SET-COMPILER is about emerging
>consensus. At the moment, we only have a very inadequate standard mean for
>users to write their own words with special compilation semantics, and that
>one must go.
We have no standard for that.
>I won't support dual-xt.
"One vote against would still be a rough consensus."
>That was an implementation option in ANS Forth for
>cmForth, and because it didn't receive enough review, you figured out that
>it is the only way to implement these words in ANS Forth. We did that
>review with Forth-2012, and it's no longer true, in Forth-2012, all three
>current practice implementations (STATE-smart, dual-xt, SET-COMPILER) are
>legal; and that was the original intention for ANS Forth, too.
>
>If a consensus emerges, we can narrow that down to one option.
As long as we keep S" etc, the right way to implement these words is
dual-xt. I also doubt that you can convince Forth, Inc. and the large
number of traditional systems to switch to a different way.
Therefore I think the way to find consensus is to get rid of S" etc.
Then we can get rid of dual-xt, STATE-smart words, and the
non-use2-compatible xts of VFX.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-05-03 21:07 +0100 |
| Message-ID | <mi5v3q$3u0$1@dont-email.me> |
| In reply to | #38586 |
On 25/04/2015 00:21, Bernd Paysan wrote: > 3. dual-xt has been critisized by Stephen Pelc, because it breaks the > conceptual unit of name and xt (where the xt is just a token for the name) I've not really been following the discussion about whether dual xt's are good or bad. But if you have a system where the xt is the address of a pointer that points to a small structure containing: 1. a pointer to code implementing interpretation semantics 2. a pointer to code implementing compilation semantics This is clearly less efficient as it has another level of indirection. But ignoring that, if whatever uses the single xt chooses the correct implementation pointer do the problems associated with dual xts go away? If not what problems remain? -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-03 23:25 +0100 |
| Message-ID | <mi6762$5eh$1@dont-email.me> |
| In reply to | #38799 |
on 03/05/2015 21:07:20, Gerry Jackson wrote:
> On 25/04/2015 00:21, Bernd Paysan wrote:
>> 3. dual-xt has been critisized by Stephen Pelc, because it breaks the
>> conceptual unit of name and xt (where the xt is just a token for the name)
>
> I've not really been following the discussion about whether dual xt's
> are good or bad. But if you have a system where the xt is the address
> of a pointer that points to a small structure containing:
> 1. a pointer to code implementing interpretation semantics
> 2. a pointer to code implementing compilation semantics
>
> This is clearly less efficient as it has another level of indirection.
My solution is a cell before the standard interpretation XT that contains
the offset back to the header that contains (amongst other things) a
compilation token that points to the compilation XT. The (slight)
inefficency is in compilation, not interpretation.
: >ct ( xt -- ct ) dup cell- @ + ; \ given an xt, get the ct
begin-structure head% ( header)
..
lfield: head.ct \ compile token action: COMPILE, or execute if IMMEDIATE
lfield: head.xtptr \ ptr to the xt
..
The head.ct would be the target of VFX's SET-COMPILER. The action while
interpreting is <xt> EXECUTE and when compiling is <xt> >CT 2@ EXECUTE.
> But ignoring that, if whatever uses the single xt chooses the correct
> implementation pointer do the problems associated with dual xts go
> away? If not what problems remain?
>
None that I've found so far.
[toc] | [prev] | [next] | [standalone]
| From | gwj.nexus@gmail.com |
|---|---|
| Date | 2015-05-05 10:53 -0700 |
| Message-ID | <18e7c2dd-17ad-4c72-8224-d2668e3cc02c@googlegroups.com> |
| In reply to | #38802 |
So if I understand you, each word has an additional cell to get you to a compilation xt. The scheme I outlined doesn't as all colon definitions, for example, share the data structure that gets to the interpretation and compilation code Not that an extra cell per word is important given the amount of memory available in modern systems. OT: I've had to use Google Groups to reply, and it's awful.
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-05 19:10 +0100 |
| Message-ID | <mib0vs$7gr$1@dont-email.me> |
| In reply to | #38845 |
on 05/05/2015 18:54:00, wrote: > So if I understand you, each word has an additional cell to get you to > a co mpilation xt. The scheme I outlined doesn't as all colon > definitions, for e xample, share the data structure that gets to the > interpretation and compil ation code Not that an extra cell per word > is important given the amount of memory available in modern systems. > > OT: I've had to use Google Groups to reply, and it's awful. > Don't snip as much either; I can't work out of you're replying to me or someone else since I use an unthreaded reader.
[toc] | [prev] | [next] | [standalone]
| From | Gerry <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2015-05-06 21:41 +0100 |
| Message-ID | <midu6t$kme$1@dont-email.me> |
| In reply to | #38846 |
On 05/05/2015 19:10, Alex McDonald wrote: > on 05/05/2015 18:54:00, wrote: >> So if I understand you, each word has an additional cell to get you to >> a co mpilation xt. The scheme I outlined doesn't as all colon >> definitions, for e xample, share the data structure that gets to the >> interpretation and compil ation code Not that an extra cell per word >> is important given the amount of memory available in mode'm rn systems. >> >> OT: I've had to use Google Groups to reply, and it's awful. >> > > Don't snip as much either; I can't work out of you're replying to me or > someone else since I use an unthreaded reader. > Sorry about that, I used Google groups on an Android tablet and it snipped everything, I didn't see an option to include the text I was replying to. I've borrowed a laptop with Thunderbird for this response. I was responding to this bit of your message: <quote sender="Alex McD">My solution is a cell before the standard interpretation XT that contains the offset back to the header that contains (amongst other things) a compilation token that points to the compilation XT. The (slight) inefficency is in compilation, not interpretation. : >ct ( xt -- ct ) dup cell- @ + ; \ given an xt, get the ct begin-structure head% ( header) .. lfield: head.ct \ compile token action: COMPILE, or execute if IMMEDIATE lfield: head.xtptr \ ptr to the xt .. The head.ct would be the target of VFX's SET-COMPILER. The action while interpreting is <xt> EXECUTE and when compiling is <xt> >CT 2@ EXECUTE.</quote> Gerry
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-07 11:05 +0100 |
| Message-ID | <mifdbg$5v8$1@dont-email.me> |
| In reply to | #38872 |
on 06/05/2015 21:41:02, Gerry wrote: > On 05/05/2015 19:10, Alex McDonald wrote: >> on 05/05/2015 18:54:00, wrote: >>> So if I understand you, each word has an additional cell to get you to >>> a co mpilation xt. The scheme I outlined doesn't as all colon >>> definitions, for e xample, share the data structure that gets to the >>> interpretation and compil ation code Not that an extra cell per word >>> is important given the amount of memory available in mode'm rn systems. >>> >>> OT: I've had to use Google Groups to reply, and it's awful. >>> >> >> Don't snip as much either; I can't work out of you're replying to me or >> someone else since I use an unthreaded reader. >> > > Sorry about that, I used Google groups on an Android tablet and it > snipped everything, I didn't see an option to include the text I was > replying to. I've borrowed a laptop with Thunderbird for this > response. > > I was responding to this bit of your message: > > <quote sender="Alex McD">My solution is a cell before the standard > interpretation XT that contains > the offset back to the header that contains (amongst other things) a > compilation token that points to the compilation XT. The (slight) > inefficency is in compilation, not interpretation. > >: >ct ( xt -- ct ) dup cell- @ + ; \ given an xt, get the ct > > begin-structure head% ( header) > .. > lfield: head.ct \ compile token action: COMPILE, or execute if > IMMEDIATE lfield: head.xtptr \ ptr to the xt > .. > > The head.ct would be the target of VFX's SET-COMPILER. The action > while interpreting is <xt> EXECUTE and when compiling is <xt> >CT 2@ > EXECUTE.</quote> > > Gerry > > > Yes, there's an extra back pointer in front of the XT (actually, it's an offset from the XT to the parent header; it doesn't require relocation if & when the code is moved). Gforth allows you to find the NT (name token) from the XT, but the doc claims it's not guaranteed to work. I suspect it uses a very similar scheme to my original design, a brute force search of the dictionaries to find a header with a matching XT pointer. This was all very messy when trying to find the CT (compilation token). So I added a back offset which at 4 bytes is reasonably small. Even though it's on the code area, it doesn't impact the run time performance at all as the data is only read and only at compile time. As it's an offset, even if I move it to 64 bit Forth (real soon now ;), its 4 byte size and ability to address 2GB of code & headers is more than adequate. Of course, the CT could have been stored as 8 bytes in front of the XT and taken out of the header. The entire header could have got the same treatment. With Intel chips, they don't take kindly to having data (especially data that's modified) in the code area, hence I split them out.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-08 11:35 +0000 |
| Message-ID | <2015May8.133518@mips.complang.tuwien.ac.at> |
| In reply to | #38883 |
"Alex McDonald" <blog@rivadpm.com> writes:
>Yes, there's an extra back pointer in front of the XT (actually, it's an
>offset from the XT to the parent header; it doesn't require relocation if
>& when the code is moved). Gforth allows you to find the NT (name token)
>from the XT, but the doc claims it's not guaranteed to work. I suspect it
>uses a very similar scheme to my original design, a brute force search of
>the dictionaries to find a header with a matching XT pointer.
No, Gforth up to 0.7.x just tries potential NTs (i.e., addresses
preceeding the code field address), and checks whether that looks like
a name field for the xt. Two failure modes: 1) If the xt has no name;
2) If the heuristic match thinks it sees a name field, but that just
happens to be a bit pattern that fits.
The development version has a different header structure that avoids
failure mode 2 (and, I think, also 1).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 14:09 +0000 |
| Message-ID | <2015May6.160922@mips.complang.tuwien.ac.at> |
| In reply to | #38845 |
gwj.nexus@gmail.com writes:
>So if I understand you, each word has an additional cell to get you to a co=
>mpilation xt.
I don't know whio you are replying to, but anyway: Conceptually yes,
if you want separate compilation semantics, you need an extra compsem
field; if you want an optimizing "COMPILE,", you need an extra
compile, field.
In the implementation, you can optimize that, of course. E.g., have
two flags, one representing the default compsem (then you do not need
the compsem field), one representing the default compile, (then you
don't need the compile, field). We also have discussed other
approaches to reducing the required space. I am not sure that such
optimizations are worth the extra code complexity, though.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-04 03:08 +0200 |
| Message-ID | <mi6gp9$utq$1@dont-email.me> |
| In reply to | #38799 |
Gerry Jackson wrote: > On 25/04/2015 00:21, Bernd Paysan wrote: >> 3. dual-xt has been critisized by Stephen Pelc, because it breaks the >> conceptual unit of name and xt (where the xt is just a token for the >> name) > > I've not really been following the discussion about whether dual xt's > are good or bad. But if you have a system where the xt is the address of > a pointer that points to a small structure containing: > 1. a pointer to code implementing interpretation semantics > 2. a pointer to code implementing compilation semantics > > This is clearly less efficient as it has another level of indirection. > But ignoring that, if whatever uses the single xt chooses the correct > implementation pointer do the problems associated with dual xts go away? > If not what problems remain? What remains is Anton's difference between SET-COMPILER and SET-COMPSEM. I'm opposed to it, because it makes explaining the language considerably more difficult to people. If it's difficult to explain, it is wrong. IMHO, Anton exposes an "I can only think complicated" trait here (many people can only think complicated and can't take the shortcuts, because that requires out-of-the-box thinking). Forth, as Anton wants it, is that complicated: compilation semantics is different from what COMPILE, does. That's due to his "use 2" corner cases (normal "use 2" is not a problem). My OOTB thninking is: When we have two closely related concepts, isn't it better to heat up the Forth standard a bit and allow it to change so that the two closely related concepts can be made one? Standards usually have to deal with different ways to implement this. That results in complexity by itself, since the standard has to abstract from the different ways. So we have a name token and an execution token. In current Gforth git head, xt and nt are the same thing. Mostly, because there's still the capability for dual-xt, which makes interpret/compile: xts an exception (SET-COMPSEM xt's a semi-exception - name, xt and interpretation semantics are tied together). -- 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 | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-04 09:23 +0100 |
| Message-ID | <mi7a7u$v6q$1@dont-email.me> |
| In reply to | #38806 |
on 04/05/2015 02:08:52, Bernd Paysan wrote: > Gerry Jackson wrote: > >> On 25/04/2015 00:21, Bernd Paysan wrote: >>> 3. dual-xt has been critisized by Stephen Pelc, because it breaks the >>> conceptual unit of name and xt (where the xt is just a token for the >>> name) >> >> I've not really been following the discussion about whether dual xt's >> are good or bad. But if you have a system where the xt is the address of >> a pointer that points to a small structure containing: >> 1. a pointer to code implementing interpretation semantics >> 2. a pointer to code implementing compilation semantics >> >> This is clearly less efficient as it has another level of indirection. >> But ignoring that, if whatever uses the single xt chooses the correct >> implementation pointer do the problems associated with dual xts go away? >> If not what problems remain? > > What remains is Anton's difference between SET-COMPILER and > SET-COMPSEM. I'm opposed to it, because it makes explaining the > language considerably more difficult to people. If it's difficult to > explain, it is wrong. > > IMHO, Anton exposes an "I can only think complicated" trait here (many > people can only think complicated and can't take the shortcuts, > because that requires out-of-the-box thinking). Forth, as Anton wants > it, is that complicated: compilation semantics is different from what > COMPILE, does. That's due to his "use 2" corner cases (normal "use 2" > is not a problem). Can you give an example of a use 2 case that is normal vs (for want of a better word) an abnormal one? > > My OOTB thninking is: When we have two closely related concepts, isn't > it better to heat up the Forth standard a bit and allow it to change > so that the two closely related concepts can be made one? > > Standards usually have to deal with different ways to implement this. > That results in complexity by itself, since the standard has to > abstract from the different ways. So we have a name token and an > execution token. In current Gforth git head, xt and nt are the same > thing. Mostly, because there's still the capability for dual-xt, which > makes interpret/compile: xts an exception (SET-COMPSEM xt's a > semi-exception - name, xt and interpretation semantics are tied > together). >
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-04 20:32 +0200 |
| Message-ID | <mi8duc$8me$1@dont-email.me> |
| In reply to | #38807 |
Alex McDonald wrote: >> IMHO, Anton exposes an "I can only think complicated" trait here (many >> people can only think complicated and can't take the shortcuts, >> because that requires out-of-the-box thinking). Forth, as Anton wants >> it, is that complicated: compilation semantics is different from what >> COMPILE, does. That's due to his "use 2" corner cases (normal "use 2" >> is not a problem). > > Can you give an example of a use 2 case that is normal vs (for want of a > better word) an abnormal one? Assume, you want to redefine deferred words, you write : defers ( "name" -- ) ' defer@ compile, ; immediate That's use 2, the token obtained by defer@ is usually executed by defers. Standard case is something like Defer hello : colloquial ." Hi" ; ' colloquial is hello Abnormal case (using comp: as syntactic sugar for SET-COMPILER): : weird ." Hi" ; comp: drop ]] "Bye" type [[ ; ' weird is hello hello Hi ok : weird2 defers hello ." all" ; ' weird2 is hello hello Bye all ok -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-06 13:26 +0000 |
| Message-ID | <2015May6.152633@mips.complang.tuwien.ac.at> |
| In reply to | #38806 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Gerry Jackson wrote:
>
>> On 25/04/2015 00:21, Bernd Paysan wrote:
>>> 3. dual-xt has been critisized by Stephen Pelc, because it breaks the
>>> conceptual unit of name and xt (where the xt is just a token for the
>>> name)
>>
>> I've not really been following the discussion about whether dual xt's
>> are good or bad. But if you have a system where the xt is the address of
>> a pointer that points to a small structure containing:
>> 1. a pointer to code implementing interpretation semantics
>> 2. a pointer to code implementing compilation semantics
>>
>> This is clearly less efficient as it has another level of indirection.
>> But ignoring that, if whatever uses the single xt chooses the correct
>> implementation pointer do the problems associated with dual xts go away?
>> If not what problems remain?
>
>What remains is Anton's difference between SET-COMPILER and SET-COMPSEM.
>I'm opposed to it, because it makes explaining the language considerably
>more difficult to people. If it's difficult to explain, it is wrong.
I find it considerably harder to explain how to use COMPILE, if it
performs the compilation semantics, as you propose, rather than
compiling the EXECUTE semantics represented by the xt. Instead of
saying:
"Here we want to delay execution by one level, so we use COMPILE,"
I would have to say:
"Here we want to delay execution by one level; the general way to do
it is to use POSTPONE LITERAL POSTPONE EXECUTE, but that is slow. So
if you are sure that you always ever get only xts of words with
default compilation semantics, you can use COMPILE,."
And of course the programmer would then use COMPILE, and have to
document the restriction on the xts, and another user would still pass
a word for which he used SET-COMPILER to implement non-default
compilation semantics (rather than SET-COMPSEM, which does not exist
in your setup), and he would get surprising results.
Of course he would have made a mistake, just like someone who programs
"undefined behaviour" in C makes a mistake, but IMO laying such traps
is not the sign of a well-designed system, especially if we know ways
to avoid them, as we do here.
And even if nobody ever falls into this trap (like nobody ever fell
into the STATE-smart trap), there are still the burdens of the
increased complexity of explaining how to use COMPILE, correctly, the
burden on the programmer to decide whether to go for generality or
performance (and if the latter, the burden to document the
restrictions), and the burden on the user of the word containing
COMPILE, to find out whether the xt he wants to pass actually
satisfies the documented restrictions.
>IMHO, Anton exposes an "I can only think complicated" trait here (many
>people can only think complicated and can't take the shortcuts, because that
>requires out-of-the-box thinking). Forth, as Anton wants it, is that
>complicated: compilation semantics is different from what COMPILE, does.
>That's due to his "use 2" corner cases (normal "use 2" is not a problem).
No need for you to go into Hugh Aguilar mode. If you want it simple,
go for single-xt+immediate-flag (compile-only is already too complex,
as we worked out); I suggested that, you rejected it, because
programmers will work around it with inadequate means to get their
separate compilation semantics; if you are right about that, and (a
significant number) of progammers want separate compilation semantics,
then it's these programmers who want the complexity. And then we
should do it properly rather than an "out-of-the-box shortcut" that
results in holes and traps.
>My OOTB thninking is: When we have two closely related concepts, isn't it
>better to heat up the Forth standard a bit and allow it to change so that
>the two closely related concepts can be made one?
In that case, the better approach is to go with SET-COMPSEM only (or
make SET-COMPILER behave as SET-COMPSEM). Then COMPILE, will work
correctly in all cases. The only disadvantage is that, in a system
like VFX, while "+" will be compiled efficently from the
text-interrpeter, compiling it with "['] + compile," will be less
efficient. Of course, nothing would prevent VFX from having
SET-COMPILER for internal code generator use in addition to the
SET-COMPSEM that users use for defining separate compilation
semantics.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-06 20:00 +0200 |
| Message-ID | <midkpt$dlj$1@dont-email.me> |
| In reply to | #38861 |
Anton Ertl wrote: > I find it considerably harder to explain how to use COMPILE, if it > performs the compilation semantics, as you propose, rather than > compiling the EXECUTE semantics represented by the xt. Instead of > saying: > > "Here we want to delay execution by one level, so we use COMPILE," > > I would have to say: No, Anton, you don't. You just say that COMPILE, performs the compilation semantics. You don't have to explain that it is different in the text interpreter vs. the tokenized form, you don't have to explain that FIND may return two different xts depending on STATE, etc. All you have to do for that is to let lose of your beloved equivalence, which is something your students don't know without being taught. > And of course the programmer would then use COMPILE, and have to > document the restriction on the xts, This documentation is required, anyhow. We document special compilaton semantics for every standard word which has it, and so should the user. > and another user would still pass > a word for which he used SET-COMPILER to implement non-default > compilation semantics (rather than SET-COMPSEM, which does not exist > in your setup), and he would get surprising results. No, because he has been taught that COMPILE, executes the SET-COMPILER semantics, and if you don't have it, it's a known default. It's only surprising if you have a different mental model, which you do, but it's not something people are born with, and as far as I've seen the level of understanding of this concept, I think very few people share your mental model. In other words: You are totally locked into a world-view which very few people share with you, but you can't see that your lock-in. You think it's "natural" to think that way. > Of course he would have made a mistake, just like someone who programs > "undefined behaviour" in C makes a mistake, but IMO laying such traps > is not the sign of a well-designed system, especially if we know ways > to avoid them, as we do here. No, we even create more potential pitfalls by having two concepts which seem to be related, but have clearly different effects. This is dangerous. People don't get sublte differences. You explain people that for the text interpreter, you need SET-COMPSEM to define compilation actions. And for the xt, you need SET-COMPILER to define the special COMPILE, action, which is closely related, but somehow different. Having this sort of sublte difference is looking for troubles. This part of the Forth system is complicated enough that people have problems getting into, especially, because we are talking about things that don't happen in other programming languages. DOES> used to be the concept of Forth which most people trying to learn Forth failed to understand. Words like SET-COMPILER and SET-COMPSEM are in the same ballpark. It is already difficult to teach them one of this concept, left alone two slightly different ones. > And even if nobody ever falls into this trap (like nobody ever fell > into the STATE-smart trap), Apart from you, I don't know any other example. This thing you fell over was in bigForth for years, IIRC it was taken over from volksForth. Your problem was that you had a wrong mental model of how Forth compilation works, caused by the ANS Forth standard. They talk about semantics. It actually was a state of the system (back then, STATE-smart was common). This discrepancy between actual implementation and the way the TC wrote about it made you fall into that trap. Most people didn't read the ANS Forth document to understand Forth, but text books and source code (with STATE-smart words). Therefore, they didn't have that mental model. The concept of semantics is actually a good idea, but it is something we should revisit, because it never did match with reality. Apart from Gforth, which was changed to match with the standard. That's the wrong way round. > there are still the burdens of the > increased complexity of explaining how to use COMPILE, correctly, the > burden on the programmer to decide whether to go for generality or > performance (and if the latter, the burden to document the > restrictions), and the burden on the user of the word containing > COMPILE, to find out whether the xt he wants to pass actually > satisfies the documented restrictions. No, that's wrong. That's under *your* assumption what COMPILE, should do. It's not going to do that after the change. Therefore, you don't have to think about it that way. I think you are the most problematic person to be taught the new semantics, because you have way too much a-priori knowledge which needs to be untaught. You have fully bought the ANS Forth semantics stuff, the rest of the Forth world didn't. > No need for you to go into Hugh Aguilar mode. If you want it simple, > go for single-xt+immediate-flag (compile-only is already too complex, > as we worked out); I suggested that, you rejected it, because > programmers will work around it with inadequate means to get their > separate compilation semantics; Well, maybe you are right and I should go that way. After all, just like the complaint about SET-COMPILER, there's only one guy who complains about STATE-smart: you. Ignore that guy, everybody else is happy ;-). Actually, it's not exactly that way. There was an RFI about STATE-smart words which the TC answered, it was about using STATE-smart words for optimization (example: + as state-smart word). The TC response was that this was the wrong approach. So there is a consensus about not using STATE- smart for optimizations. Instead, there's a much broader consensus for using SET-COMPILER for optimizations (even you agree). Jenny Brien mentioned that you can't get cmForth-like dual-xt Forths completely standardized, and *that* particular problem was the reason: They used dual-xt for optimization, actually, worse: They used dual-xt to actually compile the primitives. And at least for return-stack words, that optimization is crucial, if you don't optimize, they don't work. I.e. in cmForth, you can't do ['] >r compile, and get the expected result. Actually, after your "can we tick EXIT" question, that *is* standard, but it is a stupid way of being standard: You can't do that, because you can't meaningfully tick >R. These problems are all holes of the needlessly complicated model of the current standard. > if you are right about that, and (a > significant number) of progammers want separate compilation semantics, > then it's these programmers who want the complexity. And then we > should do it properly rather than an "out-of-the-box shortcut" that > results in holes and traps. Treating compilation in text interpreter mode differently from compilation of xts is *not* "doing it properly", and you ignore the holes and traps this creates. See above for an example. >>My OOTB thninking is: When we have two closely related concepts, isn't it >>better to heat up the Forth standard a bit and allow it to change so that >>the two closely related concepts can be made one? > > In that case, the better approach is to go with SET-COMPSEM only (or > make SET-COMPILER behave as SET-COMPSEM). > > Then COMPILE, will work correctly in all cases. Anton, not "correctly", but "your way". > The only disadvantage is that, in a system > like VFX, while "+" will be compiled efficently from the > text-interrpeter, compiling it with "['] + compile," will be less > efficient. And "['] >r compile," might not work at all. Yes, and why? Because there's a subtle difference, which is unnecessary and complicates the whole language. You are creating an artificial difference between things that IMHO should *not* be different. They are different, because the TC did make a relatively good job with the semantics, but not a perfect job. The difference is just a mistake! > Of course, nothing would prevent VFX from having > SET-COMPILER for internal code generator use in addition to the > SET-COMPSEM that users use for defining separate compilation > semantics. That doesn't work. The "don't bury your tools" philosophy means it is documented and people will be able to use it. You now have to educate people why not use SET-COMPILER, why use SET-COMPSEM instead, even though it has the disadvantage that it works only in the text interpreter, and not with COMPILE,. It is much easier to tell people that ' FOO is just *the* token for FOO (not "a STATE-dependent token, lacking the information whether it's immediate"), and that you can achive the interpreter part by doing EXECUTE and the compiler part by doing COMPILE, on it. That's a very straight-forward equivalence, no stublte differences, and it's easy to memorize what you get in the corner cases (special compilation semantics is a corner case). Those out-of-the-box shortcuts are necessary to simplify concepts; if you have a pure legacy view, you can't take these shortcuts, and you are making the world more complex than it needs to be. The box is not the boundary of the universe. It's just cardboard. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2015-05-06 13:24 -0700 |
| Message-ID | <f10e5c36-97e1-46ee-8413-748f0e6e0d73@googlegroups.com> |
| In reply to | #38866 |
On Wednesday, May 6, 2015 at 11:00:30 AM UTC-7, Bernd Paysan wrote:
> You are totally locked into a world-view which very few
> people share with you, but you can't see that your lock-in. You think it's
> "natural" to think that way.
So long as Anton Ertl shares his world-view with his bosses, then he keeps his job --- this world-vies is that it is impossible to write an outer-interpreter in standard Forth and hence impossible to write a cross-compiler. It doesn't have to be "natural" to the Forth world (it never existed prior to ANS-Forth) --- so long as the boss says that it is natural, then you say that only a fool would expect to write a cross-compiler in ANS-Forth, and if the boss says that the sky is orange, then you say that only madmen see it as being blue.
> Jenny Brien mentioned that you can't get cmForth-like dual-xt Forths
> completely standardized, and *that* particular problem was the reason: They
> used dual-xt for optimization, actually, worse: They used dual-xt to
> actually compile the primitives. And at least for return-stack words, that
> optimization is crucial, if you don't optimize, they don't work.
I don't know what "cmForth-like dual-xt Forths" mean, and I don't care. In MFX most words (DUP etc.) existed in both HOST mode and TARG mode. The TARG mode version worked on the target processor and the HOST mode version was immediate and worked on the host processor (it compiled the TARG mode word). These words were in different word-lists and had different xt values. Because it was possible to examine an xt and determine which word-list it was in, there was never any confusion about which word was which. There were some words (hand-written immediate words such as IF) that existed only in HOST mode and didn't have a TARG mode version.
Now that I have figured out how to disambiguify ANS-Forth, I can do this in ANS-Forth too.
> I.e. in
> cmForth, you can't do
>
> ['] >r compile,
>
> and get the expected result. Actually, after your "can we tick EXIT"
> question, that *is* standard, but it is a stupid way of being standard: You
> can't do that, because you can't meaningfully tick >R.
Disambiguify >R like this:
: >r state @ 0= abort" *** no interpretation semantics for: >R ***"
postpone >r ; immediate
Now you can tick >R meaningfully. If you execute it in compilation mode, it will work as expected. If you execute it in interpretation mode, then you get an abort with this message: " *** no interpretation semantics for: >R ***" This is expected too --- and the error message explains exactly what the mistake was, so your bug can be easily fixed.
Tick has always been problematic to use, because it doesn't tell you if your word is immediate or non-immediate. This has always been true, and continues to be true with my disambiguifiers. This is why FIND is used when writing outer-interpreters rather than tick --- for the most part, tick is just a convenience for cases in which you know a-priori if the word is non-immediate or immediate, but you can't rely on a-priori knowledge when you are working with a user-entered string rather than a string that you typed in yourself as part of your own source-code.
All of this stuff seems easy and obvious to me. The fact that you two are pondering it and unable to understand it, implies one of two things:
1.) You are both dumb as beagles.
2.) You are playing dumb in an effort to hide your agenda, which is to make cross-compilation impossible in a standard program, so cross-compilers can only be written by compiler-vendors using carnal knowledge.
In case #2, I have already defeated you with my disambiguifiers.
In case #1, you should just resign from the Forth-200x committee on the basis that you aren't qualified.
> > The only disadvantage is that, in a system
> > like VFX, while "+" will be compiled efficently from the
> > text-interrpeter, compiling it with "['] + compile," will be less
> > efficient.
>
> And "['] >r compile," might not work at all.
In MFX, there were actually a total of three versions of + and ! and most other words:
SYSTEM --- These ran on the host computer and accessed host memory. This is what executed in interpretation mode, and compilation mode of SYSTEM or HOST words. These could be either immediate or non-immediate. These were actually the FORTH-WORDLIST (FORTH vocabulary in Forth-83) words built into the system.
HOST --- These ran on the host computer and accessed target memory (the image that would later get uploaded). These were immediate, so they got executed in compilation mode of TARG words, but not of HOST words in which case they weren't found (wrong word-list).
TARG --- These ran on the target computer and accessed target memory. These were non-immediate (there was no outer-interpreter on the target computer).
For the most part, nobody ever wrote SYSTEM words (this is why I sometimes say for convenience that there are two versions: HOST and TARG) --- programmers only wrote HOST or TARG words (actually, a novice could get by only writing TARG words --- HOST words were only for meta-compiling, which is more advanced than many users want to get into).
I had these words for ticking in interpretation mode: S' H' and T'
I had these words for ticking in compilation mode: [S'] [H'] and [T']
The programmer just used whichever ticker was appropriate to what he wanted to obtain (use S' to get a SYSTEM word, use H' to get a HOST word, use T' to get a TARG word). I didn't have ' and ['] because these would have been ambiguous (I don't tolerate ambiguity). This system is very simple --- there is no confusion for the programmer --- anybody can learn to use such a system with minimal instruction (my coworker figured it out from my one page documentation and never had to ask any questions).
I figured all of this out in 1994 when I wrote MFX --- it is exasperating for me to see the Forth-200x committee baffled by the concept of Forth compilation in the year 2015 --- I'm leaning toward the "dumb as beagles" explanation, as this stuff is really quite easy --- if you just engage your brain, it should be obvious.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-08 12:07 +0000 |
| Message-ID | <2015May8.140712@mips.complang.tuwien.ac.at> |
| In reply to | #38866 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> I find it considerably harder to explain how to use COMPILE, if it
>> performs the compilation semantics, as you propose, rather than
>> compiling the EXECUTE semantics represented by the xt. Instead of
>> saying:
>>
>> "Here we want to delay execution by one level, so we use COMPILE,"
>>
>> I would have to say:
>
>No, Anton, you don't. You just say that COMPILE, performs the compilation
>semantics.
But it doesn't, not even on VFX:
: foo ." foo" ; immediate ok
: bar [ ' foo compile, ] ; ok
: bar2 foo ; foo ok
In BAR2 you can see the compilation semantics of FOO at work, in BAR
you see something different: the execution semantics of FOO being
appended to the current definition. This code works in this way on
every standard system, including VFX, so no system behaves the way you
want to document.
>You don't have to explain that it is different in the text
>interpreter vs. the tokenized form
What is that about? "Tokenized form" does not occur in the standard
nor any teaching material I know about Forth. Why should one have to
explain that?
>you don't have to explain that FIND may
>return two different xts depending on STATE, etc.
If you don't want to explain that, get rid of non-default
non-immediate compilation semantics. Or get rid of FIND.
>All you have to do for that is to let lose of your beloved equivalence,
>which is something your students don't know without being taught.
Somehow a number of people, including you, learned, and, more
importantly, used that equivalence without me having to teach them.
This equivalence has worked and has been used since the good old days
of threaded code when we still used "," instead of COMPILE,.
>> And of course the programmer would then use COMPILE, and have to
>> document the restriction on the xts,
>
>This documentation is required, anyhow. We document special compilaton
>semantics for every standard word which has it, and so should the user.
I am not referring to documenting words with special compilation
semantics, but words that take an xt as parameter, e.g., DEFINES in
mini-oof. Despite mini-oof having much more documentation from you
than any other code I have ssen from you, you fail to mention any
restrictions on the xts that you pass to it.
>> and another user would still pass
>> a word for which he used SET-COMPILER to implement non-default
>> compilation semantics (rather than SET-COMPSEM, which does not exist
>> in your setup), and he would get surprising results.
>
>No, because he has been taught that COMPILE, executes the SET-COMPILER
>semantics, and if you don't have it, it's a known default.
How should that user know that the xt passed to DEFINER in mini-oof
may be passed to COMPILE,?
>It's only
>surprising if you have a different mental model, which you do, but it's not
>something people are born with, and as far as I've seen the level of
>understanding of this concept, I think very few people share your mental
>model.
Concerning the use of COMPILE, as delayed EXECUTE, I think that many
people share that, because it already worked that way on the classic
systems. Concerning non-default non-immediate compilation semantics,
admittedly many people (maybe the majority) probably still think in
terms of STATE-smart words rather than in the Forth-94 concepts, so if
you make this a popularity contest, maybe we should standardize
STATE-smartness and be done with it.
>> Of course he would have made a mistake, just like someone who programs
>> "undefined behaviour" in C makes a mistake, but IMO laying such traps
>> is not the sign of a well-designed system, especially if we know ways
>> to avoid them, as we do here.
>
>No, we even create more potential pitfalls by having two concepts which seem
>to be related, but have clearly different effects. This is dangerous.
>People don't get sublte differences. You explain people that for the text
>interpreter, you need SET-COMPSEM to define compilation actions. And for
>the xt, you need SET-COMPILER to define the special COMPILE, action, which
>is closely related, but somehow different.
No, my explanation is: For changing the compilation semantics (e.g.,
for S"), you need SET-COMPSEM. For optimizing code generation
(without changing the meaning, e.g., for +), you use SET-COMPILER.
I see the difference between changing the meaning of a word and not
changing it as a fundamental difference, not a subtle one.
>DOES> used to be the concept of Forth which most people trying to learn
>Forth failed to understand. Words like SET-COMPILER and SET-COMPSEM are in
>the same ballpark. It is already difficult to teach them one of this
>concept, left alone two slightly different ones.
If it is too dificult, teach them none. Stick with IMMEDIATE for
compilation semantics, and leave optimization to the compiler.
However, if you want to provide a way to change compilation semantics,
and also provide them a way to do optimization, as you do, then
teaching one word for each purpose is easier than teaching one word
for both purposes with a number of caveats because that one word does
not work for the other purpose in all cases. So you advocate leaving
the caveats away; that's certainly going to make teaching simpler,
it's just that the result will be more bugs.
>> And even if nobody ever falls into this trap (like nobody ever fell
>> into the STATE-smart trap),
>
>Apart from you, I don't know any other example.
https://www.complang.tuwien.ac.at/forth/dpans-html/queries/a0007.html
The involved persons here are Wonyong Koh and Jonah Thomas. And
STATE-smartness was an issue long before I took any part in
discussions. Why, do you think, do we have CHAR and [CHAR] in
Forth-94 rather than the Forth-83 uncontrolled reference word ASCII?
>> there are still the burdens of the
>> increased complexity of explaining how to use COMPILE, correctly, the
>> burden on the programmer to decide whether to go for generality or
>> performance (and if the latter, the burden to document the
>> restrictions), and the burden on the user of the word containing
>> COMPILE, to find out whether the xt he wants to pass actually
>> satisfies the documented restrictions.
>
>No, that's wrong. That's under *your* assumption what COMPILE, should do.
>It's not going to do that after the change. Therefore, you don't have to
>think about it that way.
You mean, just because I would no longer think about it that way, all
the use-2 uses of COMPILE, and the thoughts of their programmers would
go away?
And even if it did, what about the future? Will no programmer ever
think again that he could speed his program up by using COMPILE,
instead of POSTPONE LITERAL POSTPONE EXECUTE?
>> If you want it simple,
>> go for single-xt+immediate-flag (compile-only is already too complex,
>> as we worked out); I suggested that, you rejected it, because
>> programmers will work around it with inadequate means to get their
>> separate compilation semantics;
>
>Well, maybe you are right and I should go that way. After all, just like
>the complaint about SET-COMPILER, there's only one guy who complains about
>STATE-smart: you. Ignore that guy, everybody else is happy ;-).
>
>Actually, it's not exactly that way.
And it's also not exactly that I am the only one who uses COMPILE, for
delayed EXECUTEion. Even you have done that, several times.
>Jenny Brien mentioned that you can't get cmForth-like dual-xt Forths
>completely standardized, and *that* particular problem was the reason: They
>used dual-xt for optimization, actually, worse: They used dual-xt to
>actually compile the primitives.
The particular problem with cmForth that has been discussed in the
past is what happens if somebody redefines a word that's in the
compilation wordlist. It would land in the ordinary wordlist and, in
compile state, would fail to shadow the earlier system-supplied
definition. That problem has nothing to do with optimization. One
could fix that problem, but the resulting system would be just more
complex and have no benefits over other dual-xt approaches such as the
three approaches we have used in Gforth.
There is a potential problem with using SET-COMPSEM for optimization,
though: [COMPILE] does not know whether the new compilation action
implements the default compilation semantics or not. However, the
dual problem occurs if you use SET-COMPILER for changing compilation
semantics; IIRC this has been discussed a few months ago. So this
problem occurs whenever one uses either approach for both purposes.
>And at least for return-stack words, that
>optimization is crucial, if you don't optimize, they don't work. I.e. in
>cmForth, you can't do
>
>['] >r compile,
>
>and get the expected result.
True, COMPILE, did not exist in cmForth's time, but other than that, I
see no particular problem. E.g., here's how iForth-2.1 does it (and,
looking at the code for FOO, it does not optimize in COMPILE,):
FORTH> : compile, compile, ;
Redefining compile, ok
FORTH> : foo [ ' >r compile, ] r> ; ok
FORTH> : bar >r r> ; ok
FORTH> : flip execute r> ; ok
FORTH> 1 foo . 1 ok
FORTH> 1 bar . 1 ok
FORTH> 1 ' >r flip . 1 ok
FORTH> see foo
Flags: ANSI
$08166700 : foo 8BC083ED048F4500 .@.m..E.
$08166708 call >R ( $0809F64C ) offset NEAR
E83F8FF3FF h?.
$0816670D mov ebx, [ebp 0 +] dword 8B5D00 .].
$08166710 lea ebp, [ebp 4 +] dword 8D6D04 .m.
$08166713 push ebx 53 S
$08166714 ; 8B450083C504 .E..E. ok
FORTH> see >r
Flags: COMPILE-ONLY, ANSI
$0809F64C pop ebx 5B [
$0809F64D sub ebp, 4 b# 83ED04 .m.
$0809F650 pop [ebp 0 +] dword 8F4500 .E.
$0809F653 jmp ebx FFE3 c ok
>These problems are all holes of the needlessly complicated model of the
>current standard.
Which problems?
1) Incorrect shadowing is an implementation issue in dual-wordlist
systems and does not occur at all in other dual-xt systems.
2) [COMPILE] problems occur for both SET-COMPSEM and SET-COMPILER when
they are used for the wrong purpose. A solution for that problem
(and, in the case of SET-COMPILER, others) is to use SET-COMPSEM only
for changing compilation semantics and to use SET-COMPILER only for
optimization.
3) "' >R COMPILE," can be made to work without an optimizing COMPILE,,
as demonstrated by iForth-2.1.
>> if you are right about that, and (a
>> significant number) of progammers want separate compilation semantics,
>> then it's these programmers who want the complexity. And then we
>> should do it properly rather than an "out-of-the-box shortcut" that
>> results in holes and traps.
>
>Treating compilation in text interpreter mode differently from compilation
>of xts is *not* "doing it properly", and you ignore the holes and traps this
>creates. See above for an example.
Your ' >R example shows that you do not need an optimizing COMPILE,.
>> In that case, the better approach is to go with SET-COMPSEM only (or
>> make SET-COMPILER behave as SET-COMPSEM).
>>
>> Then COMPILE, will work correctly in all cases.
>
>Anton, not "correctly", but "your way".
Not just my way, but the way specified in Forth-94 and Forth-2012, and
the way used in an unknown number of programs, including programs
written by you.
>> The only disadvantage is that, in a system
>> like VFX, while "+" will be compiled efficently from the
>> text-interrpeter, compiling it with "['] + compile," will be less
>> efficient.
>
>And "['] >r compile," might not work at all.
Sure, one can botch the implementation, but one can also botch the
implementation when using SET-COMPILER. iForth-2.1 demonstrates that
one can also get it right without an optimizing COMPILE,.
>> Of course, nothing would prevent VFX from having
>> SET-COMPILER for internal code generator use in addition to the
>> SET-COMPSEM that users use for defining separate compilation
>> semantics.
>
>That doesn't work. The "don't bury your tools" philosophy means it is
>documented and people will be able to use it. You now have to educate
>people why not use SET-COMPILER, why use SET-COMPSEM instead, even though it
>has the disadvantage that it works only in the text interpreter, and not
>with COMPILE,.
If this is a VFX word and MPE documents it, then they will have to
teach them that, yes.
I see no particular problem teaching them that, though:
"If you want to change the behaviour in compilation (e.g., because you
want to parse at compile time), use SET-COMPSEM. If the word behaves
as it should when you compile it, but you want to make it more
efficient, use SET-COMPILER."
>It is much easier to tell people that ' FOO is just *the* token for FOO (not
>"a STATE-dependent token, lacking the information whether it's immediate"),
>and that you can achive the interpreter part by doing EXECUTE and the
>compiler part by doing COMPILE, on it.
Sure, and that explanation works fine for words with default
compilation semantics only. Already immediate words don't work
the way you explain it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
| From | "Alex McDonald" <blog@rivadpm.com> |
|---|---|
| Date | 2015-05-08 18:26 +0100 |
| Message-ID | <miirha$dgv$1@dont-email.me> |
| In reply to | #38898 |
on 08/05/2015 13:07:14, wrote: > Bernd Paysan <bernd.paysan@gmx.de> writes: >>Anton Ertl wrote: >>> I find it considerably harder to explain how to use COMPILE, if it >>> performs the compilation semantics, as you propose, rather than >>> compiling the EXECUTE semantics represented by the xt. Instead of >>> saying: >>> >>> "Here we want to delay execution by one level, so we use COMPILE," >>> >>> I would have to say: >> >>No, Anton, you don't. You just say that COMPILE, performs the compilation >>semantics. > > But it doesn't, not even on VFX: > >: foo ." foo" ; immediate ok >: bar [ ' foo compile, ] ; ok >: bar2 foo ; foo ok > > In BAR2 you can see the compilation semantics of FOO at work, in BAR > you see something different: the execution semantics of FOO being > appended to the current definition. This code works in this way on > every standard system, including VFX, so no system behaves the way you > want to document. > Neither it should, since it is the function of POSTPONE to append the compilation semantics. (An aside; POSTPONE, is quite useful.) >>you don't have to explain that FIND may >>return two different xts depending on STATE, etc. > > If you don't want to explain that, get rid of non-default > non-immediate compilation semantics. Or get rid of FIND. The latter. It's broken, and immediacy as a concept is becoming hard to justify when what is meant is the same interpretation and compilation effects. > >>All you have to do for that is to let lose of your beloved equivalence, >>which is something your students don't know without being taught. > > Somehow a number of people, including you, learned, and, more > importantly, used that equivalence without me having to teach them. > This equivalence has worked and has been used since the good old days > of threaded code when we still used "," instead of COMPILE,. Which was my point to Stephen Pelc upthread. COMPILE, is just , for non-ITC Forths, not an optimisation opportunity. > >>It's only >>surprising if you have a different mental model, which you do, but it's not >>something people are born with, and as far as I've seen the level of >>understanding of this concept, I think very few people share your mental >>model. > > Concerning the use of COMPILE, as delayed EXECUTE, I think that many > people share that, because it already worked that way on the classic > systems. Yes, I'm one of them. > Concerning non-default non-immediate compilation semantics, > admittedly many people (maybe the majority) probably still think in > terms of STATE-smart words rather than in the Forth-94 concepts, so if > you make this a popularity contest, maybe we should standardize > STATE-smartness and be done with it. > No, I'm not one of them. > >>DOES> used to be the concept of Forth which most people trying to learn >>Forth failed to understand. Words like SET-COMPILER and SET-COMPSEM are in >>the same ballpark. It is already difficult to teach them one of this >>concept, left alone two slightly different ones. > > If it is too dificult, teach them none. Stick with IMMEDIATE for > compilation semantics, and leave optimization to the compiler. Or rename them and have the concept & not the mechanism in the name. SET-COMPSEM becomes DO-WHEN-COMPILING SET-COMPILER becomes FOR-OPTIMIZING Or somesuch. SET-COMPILER and SET-COMPSEM are too down in the weeds.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2015-05-09 01:10 +0200 |
| Message-ID | <mijfn6$tus$1@dont-email.me> |
| In reply to | #38898 |
Anton Ertl wrote: >>No, Anton, you don't. You just say that COMPILE, performs the compilation >>semantics. > > But it doesn't, not even on VFX: > > : foo ." foo" ; immediate ok > : bar [ ' foo compile, ] ; ok > : bar2 foo ; foo ok Straw man, that's using a legacy feature which is there because the standard says you must have it - this way. >>You don't have to explain that it is different in the text >>interpreter vs. the tokenized form > > What is that about? "Tokenized form" does not occur in the standard > nor any teaching material I know about Forth. Why should one have to > explain that? The "t" in xt stands for "token". >>you don't have to explain that FIND may >>return two different xts depending on STATE, etc. > > If you don't want to explain that, get rid of non-default > non-immediate compilation semantics. Or get rid of FIND. I like to get rid of a number of needlessly complex things. I'm happy with getting rid of FIND. Since people like you oppose to the state-full simple concept of STATE+IMMEDIATE (it's simple, but then compilation and interpretation are states, not semantics), I'd like to have a state-less system which has the same simplicity. That would be EXECUTE for interpretation semantics and COMPILE, for compilation semantics. No STATE, no IMMEDIATE (except for legacy, and legacy means that legacy code compiles fine, but new code and old code doesn't have the same properties, and mixing them can lead to surprises in both ways). > Somehow a number of people, including you, learned, and, more > importantly, used that equivalence without me having to teach them. No, Anton. I'm not using this equivalence for corner cases. I'm using it only for words with default compilation semantics. > This equivalence has worked and has been used since the good old days > of threaded code when we still used "," instead of COMPILE,. But back then, we had STATE-smart for all those words with non-default compilation semantics, or plain and simple immediate compile-only words, and if I do ' " >CFA , in fig-Forth, I will get a word which parses and compiles a counted string when executed. Compilation semantics - it's immediate and compile-only. Your equivalence holds only for those words with default compilation semantics. > I am not referring to documenting words with special compilation > semantics, but words that take an xt as parameter, e.g., DEFINES in > mini-oof. Despite mini-oof having much more documentation from you > than any other code I have ssen from you, you fail to mention any > restrictions on the xts that you pass to it. It's there by example: All xts passed to defines in mini-oof are :noname xts. > How should that user know that the xt passed to DEFINER in mini-oof > may be passed to COMPILE,? By reading the documentation. The full source of mini-oof is part of the documentation. "There are two ways to achieve this with this OOF: first, you could use named words, and second, you could look up the vtable of the parent object. : :: ( class "name" -- ) ' >body @ + @ compile, ;" When you choose option 1 (named words, no :: needed), you'll get into the troubles you describe with SET-COMPSEM, too. > Concerning the use of COMPILE, as delayed EXECUTE, I think that many > people share that, because it already worked that way on the classic > systems. Since xts don't carry the immediacy flag with them, that model is too simplistic. As you notice, many people still think STATE-smart, and there, EXECUTE can be both interpretation and compilation semantics, depending on STATE. > Concerning non-default non-immediate compilation semantics, > admittedly many people (maybe the majority) probably still think in > terms of STATE-smart words rather than in the Forth-94 concepts, so if > you make this a popularity contest, maybe we should standardize > STATE-smartness and be done with it. Should be a relatively straight-forward job. Your problem seems to be that you don't want popularity to count, but a standard is about common practise, and there, popularity indeed counts. > No, my explanation is: For changing the compilation semantics (e.g., > for S"), you need SET-COMPSEM. For optimizing code generation > (without changing the meaning, e.g., for +), you use SET-COMPILER. > > I see the difference between changing the meaning of a word and not > changing it as a fundamental difference, not a subtle one. People do not think that way. When they extend a word like S" to work in interpretation, too, their mental model is that S" now does *the same thing* in interpretation mode and in compilation mode. So far, I've not seen a single case of these words where the need for that special compilation or interpretation semantics wasn't driven by the desire to make the word useful with identical syntax and effect both for interpretation and compilation. s" foo" is a string literal to foo is a value assignment object method is a method invocation This all regardless of compilation or interpretation. People who write such code *don't* want to change the meaning, rather the contrary: they want to preserve the meaning of these things. Since all these words are parsing words, they do indeed different things in compilation and interpretation. But that is an implementation detail. > If it is too dificult, teach them none. Stick with IMMEDIATE for > compilation semantics, and leave optimization to the compiler. Possible. The whole discussion was started by you, because you exposed problems understanding STATE+IMMEDIATE, and RFI 7 lists a number of real shortcomings. I suppose to take the examples of RFI 7 as test if the compiler technique is ok. Let's say, we want to count how many DUPs we compile in our source code: variable dup# :noname drop postpone dup 1 dup# +! ; : dup dup ; set-compiler It compiles correctly - tick it interprets correctly - tick what it compiles executes correctly - tick its tick compile and execute correctly, without or with little performance loss - tick [compile] works correctly - tick Anton's test: works on use 2 in OOP packages - tick Obviously it does work as Mitch Bradley expects it to work, and it even works as you expect it to work. Note that this dup here does not perform an optimization - it changes the compilation semantics of dup to *also* increment a counter at compile time. It's not a parsing word, though. Using state+immediate doesn't solve the problem. Using SET-COMPSEM results in a wrong number of counts with use 2 of that DUP, otherwise, it works fine, too. A more realistic example for this kind of stuff would be tracing changes to a variable. Let's define debug-variable: Variable debug! : debug-variable ( "name" -- ) variable [: debug! on variable, ;] set-compiler ; : ~var~ ( n addr -- ) dup body> >name .name ." from: " dup @ . ." to: " over . cr ; :noname drop debug! @ debug! off IF postpone ~var~ THEN postpone ! ; : ! ! ; set-compiler variable, is the default compiler for variables, i.e. >body postpone literal. So when I change a variable into a debug-variable, each time a store is performed afterwards, it will print a state change. debug-variable foo ok : test1 3 foo ! ; ok : test2 5 foo ! ; ok test1 foo from: 0 to: 3 ok test2 foo from: 3 to: 5 ok : test3 test1 test2 test1 ; ok test3 foo from: 5 to: 3 foo from: 3 to: 5 foo from: 5 to: 3 Doesn't work in interpretation state. Doesn't work with a late-bound ! as method. Doesn't work if there's some complicated pointer-juggling. A performance-penalty version could be made to work in more of those cases (depending how much performance you want to spend on that), so that stuff is an optimization over the naive version (where variable does that DEBUG! ON in a DOES> statement, and ! checks for that at run-time). > So you advocate leaving > the caveats away; that's certainly going to make teaching simpler, > it's just that the result will be more bugs. IMHO it's better to teach people about parsing words and recognizers, and why they should use recognizers instead of parsing words. > The involved persons here are Wonyong Koh and Jonah Thomas. And > STATE-smartness was an issue long before I took any part in > discussions. Why, do you think, do we have CHAR and [CHAR] in > Forth-94 rather than the Forth-83 uncontrolled reference word ASCII? Forth Inc. didn't have STATE at all, and they didn't like it. Probably for a reason. As explained above, STATE can do some things and can't do a lot of other things. And it's *not* just about optimization. And people don't want to change the semantics, it's just that parsing words need different implementations - it's not perceived as semantics change. > You mean, just because I would no longer think about it that way, all > the use-2 uses of COMPILE, and the thoughts of their programmers would > go away? Only the corner-case use-2 with special compilation semantics, compile-only words and such stuff is changing. You are inflating the problem. These cases already don't work as people might assume right now in a number of systems (and since assumtions may be different, with many people still thinking STATE-smart, it's not clear which system is the most unexpected one). > And even if it did, what about the future? Will no programmer ever > think again that he could speed his program up by using COMPILE, > instead of POSTPONE LITERAL POSTPONE EXECUTE? He usually can. It's a corner case where he can't. A corner case where it very likely won't work in many current Forth systems, either. We can continue as we do now, and say this sort of stuff is simply not supposed to work portably. Or we say it's supposed to work in the next standard, and we then have to chose how. STATE-smart, SET-COMPILER or dual- xt are already implemented, and the three behave different. > And it's also not exactly that I am the only one who uses COMPILE, for > delayed EXECUTEion. Even you have done that, several times. Sure. But not on your straw-man. >>These problems are all holes of the needlessly complicated model of the >>current standard. > > Which problems? The standard tries to wrap around two (Forth-94) or three (Forth-2012) different ways to implement things. That's always complicating things. > 1) Incorrect shadowing is an implementation issue in dual-wordlist > systems and does not occur at all in other dual-xt systems. That doesn't remove other dual-xt problems. > 2) [COMPILE] problems occur for both SET-COMPSEM and SET-COMPILER when > they are used for the wrong purpose. A solution for that problem > (and, in the case of SET-COMPILER, others) is to use SET-COMPSEM only > for changing compilation semantics and to use SET-COMPILER only for > optimization. [COMPILE] works only when you have a priori knowledge of what is immediate and what not. > 3) "' >R COMPILE," can be made to work without an optimizing COMPILE,, > as demonstrated by iForth-2.1. Hm, looks like iForth uses some sort of SET-COMPSEM to optimize? Is that the right approach? > Your ' >R example shows that you do not need an optimizing COMPILE,. Sure, nobody needs an optimizer. But you might want one. > Not just my way, but the way specified in Forth-94 and Forth-2012, and > the way used in an unknown number of programs, including programs > written by you. Straw man again: This use 2 works with words that have default compilation semantics, which are the non-critical words. Use 2 does exhibit considerable different behavior on the corner cases on current systems, all of them standard under Forth-2012. Some of them don't allow to tick the problematic words, others return STATE-smart xts, and so on. These use 2 as now are non-portable at least. If you want to keep all the non-portable code that exploits behavior on use 2 on different systems, we have to keep it as is: say that it is non-portable. Some people using use 2 with state-smart systems might want to keep the state-smartness, people using use 2 with dual-xt might want to preserve that semantics, and people using use 2 with SET-COMPILER systems might want to preserve their semantics. That is the real-world code. You are pretending that the real-world code out there is the code for dual-xt systems. As if there wasn't any SwiftForth (state-smart) or VFX (set-compiler). Your straw man is that COMPILE, would magically stop working on words with default compilation semantics. It doesn't! And the other straw man is that use 2 for non-default compilation semantics is somewhat crucial for you and everybody else. It can't be, because it doesn't work portable right now. It's not like the typical C standard lawyer who says we can break those programs, because they worked 20 years but the standard says it's UD. These programs are really non-portable right now across popular implementations. If we want to make the behavior of use 2 portable across popular implementations, two out of three have to give in. And it's real-world, not just like removing signed-magnitude and one's complement, which affects nobody. If we change to STATE+IMMEDIATE, SwiftForth users can keep their weird corner cases for use 2. If we change to dual-xt, Gforth users can keep their weird corner cases for use 2. And if we change to SET-COMPILER, VFX users can keep their weird corner cases for use 2. Since Gforth makes it the hardest to abuse use 2 (all compile-only words are non-tickable), it's probably the least impacted. >>It is much easier to tell people that ' FOO is just *the* token for FOO >>(not "a STATE-dependent token, lacking the information whether it's >>immediate"), and that you can achive the interpreter part by doing EXECUTE >>and the compiler part by doing COMPILE, on it. > > Sure, and that explanation works fine for words with default > compilation semantics only. If you change the concept, it works. > Already immediate words don't work the way you explain it. Immediate is a legacy concept, then marked as obsolescent. And I don't think you should explain two concepts for the same thing to newbies. I don't think you can have both and have a system that's easy to explain. That's the root of the problem now: We have a standard which tries to describe three different possible implementations with the same logical concept. That's not going to fly. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2015-05-12 16:13 +0000 |
| Message-ID | <2015May12.181357@mips.complang.tuwien.ac.at> |
| In reply to | #38901 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>>>No, Anton, you don't. You just say that COMPILE, performs the compilation
>>>semantics.
>>
>> But it doesn't, not even on VFX:
>>
>> : foo ." foo" ; immediate ok
>> : bar [ ' foo compile, ] ; ok
>> : bar2 foo ; foo ok
>
>Straw man, that's using a legacy feature which is there because the standard
>says you must have it - this way.
Are you sure you know what a straw man argument is?
Anyway, it's standard and every system implements it this way. So
it's not just common practice, but universal practice. You propose
changing that. You would need very good arguments for that, and you
failed to do that yet.
>>>You don't have to explain that it is different in the text
>>>interpreter vs. the tokenized form
>>
>> What is that about?
...
>The "t" in xt stands for "token".
No I don't have to explain that, I just explain that an execution
token stands for one semantics; EXECUTE executes it, and COMPILE,
appends it to the current definition. And I consider that simpler
than saying that an xt stands for a lot of different things, that
EXECUTE does one thing, and COMPILE, may do something completely
unrelated.
>I like to get rid of a number of needlessly complex things. I'm happy with
>getting rid of FIND. Since people like you oppose to the state-full simple
>concept of STATE+IMMEDIATE (it's simple, but then compilation and
>interpretation are states, not semantics), I'd like to have a state-less
>system which has the same simplicity.
What's wrong with
defer name>x \ not the Gforth word of the same name
: ] ['] name>compile is name>x ;
: [ [: name>interpret dup 0= -14 and throw ;] is name>x ;
\ and here the text interpreter:
parse-name find-name dup 0= -13 and throw name>x execute
>That would be EXECUTE for
>interpretation semantics and COMPILE, for compilation semantics. No STATE,
>no IMMEDIATE (except for legacy, and legacy means that legacy code compiles
>fine, but new code and old code doesn't have the same properties, and mixing
>them can lead to surprises in both ways).
IMMEDIATE fits nicely in the system above, and STATE could be
implemented to behave as it always has.
>> Somehow a number of people, including you, learned, and, more
>> importantly, used that equivalence without me having to teach them.
>
>No, Anton. I'm not using this equivalence for corner cases. I'm using it
>only for words with default compilation semantics.
That may be the case, but you have not documented that one must only
pass words with default compilation semantics to DEFINES in mini-oof.
>> This equivalence has worked and has been used since the good old days
>> of threaded code when we still used "," instead of COMPILE,.
>
>But back then, we had STATE-smart for all those words with non-default
>compilation semantics, or plain and simple immediate compile-only words, and
>if I do ' " >CFA , in fig-Forth, I will get a word which parses and compiles
>a counted string when executed. Compilation semantics - it's immediate and
>compile-only. Your equivalence holds only for those words with default
>compilation semantics.
No, it holds for all words in fig-Forth, including STATE-smart words.
STATE-smart words have other problems, but the equivalence between
EXECUTE and COMPILE, holds for them.
>> I am not referring to documenting words with special compilation
>> semantics, but words that take an xt as parameter, e.g., DEFINES in
>> mini-oof. Despite mini-oof having much more documentation from you
>> than any other code I have ssen from you, you fail to mention any
>> restrictions on the xts that you pass to it.
>
>It's there by example: All xts passed to defines in mini-oof are :noname
>xts.
That's not documentation. You pass only three xts to DEFINES, but I
don't think that you want users to think that they may pass only one
of these three xts.
>> How should that user know that the xt passed to DEFINER in mini-oof
>> may be passed to COMPILE,?
>
>By reading the documentation. The full source of mini-oof is part of the
>documentation.
>
>"There are two ways to achieve this with this OOF: first, you could use
>named words, and second, you could look up the vtable of the parent object.
>
>: :: ( class "name" -- ) ' >body @ + @ compile, ;"
So you expect that the user understands subtle implementation details
of mini-OOF in order to use it (such as the flow of the xt from
DEFINES to COMPILE,), but you don't tell that to the user.
>When you choose option 1 (named words, no :: needed), you'll get into the
>troubles you describe with SET-COMPSEM, too.
No, if the user writes a named word, there is no xt passed to the
COMPILE, in mini-oof. Sure, the user will get the compilation
semantics when he writes a named word in a definition, but that's very
familiar territory to users (they use the text interpreter a lot, much
more than ', EXECUTE, and COMPILE,).
>> Concerning the use of COMPILE, as delayed EXECUTE, I think that many
>> people share that, because it already worked that way on the classic
>> systems.
>
>Since xts don't carry the immediacy flag with them, that model is too
>simplistic.
Simple is not always better, but here it is. And anyway, it's common
practice.
>> Concerning non-default non-immediate compilation semantics,
>> admittedly many people (maybe the majority) probably still think in
>> terms of STATE-smart words rather than in the Forth-94 concepts, so if
>> you make this a popularity contest, maybe we should standardize
>> STATE-smartness and be done with it.
>
>Should be a relatively straight-forward job. Your problem seems to be that
>you don't want popularity to count, but a standard is about common practise,
>and there, popularity indeed counts.
I don't recommend STATE-smart words, but they are good-enough for the
few standard words with special compilation semantics, and I don't
recommend writing more words with special compilation semantics.
>> No, my explanation is: For changing the compilation semantics (e.g.,
>> for S"), you need SET-COMPSEM. For optimizing code generation
>> (without changing the meaning, e.g., for +), you use SET-COMPILER.
>>
>> I see the difference between changing the meaning of a word and not
>> changing it as a fundamental difference, not a subtle one.
>
>People do not think that way. When they extend a word like S" to work in
>interpretation, too, their mental model is that S" now does *the same thing*
>in interpretation mode and in compilation mode.
When they think so, they are thinking of the word plus the thing it
parses. Recognizers should replace that use.
Anyway, it should be clear to a programmer of a STATE-smart word that
it's not the same thing, because otherwise there would be no need for
STATE @ IF. I think they understand the difference, and when
appropriately documented, understand that they should use SET-COMPSEM
and not SET-COMPILER for such words.
>So far, I've not seen a single case of these words where the need for that
>special compilation or interpretation semantics wasn't driven by the desire
>to make the word useful with identical syntax and effect both for
>interpretation and compilation.
>
>s" foo" is a string literal
>to foo is a value assignment
>object method is a method invocation
>
>This all regardless of compilation or interpretation. People who write such
>code *don't* want to change the meaning, rather the contrary: they want to
>preserve the meaning of these things.
>
>Since all these words are parsing words, they do indeed different things in
>compilation and interpretation. But that is an implementation detail.
But it's obviously not an optimization. So use SET-COMPSEM, not
SET-COMPILER. Or better, define a recognizer.
>> If it is too dificult, teach them none. Stick with IMMEDIATE for
>> compilation semantics, and leave optimization to the compiler.
>
>Possible. The whole discussion was started by you, because you exposed
>problems understanding STATE+IMMEDIATE, and RFI 7 lists a number of real
>shortcomings. I suppose to take the examples of RFI 7 as test if the
>compiler technique is ok. Let's say, we want to count how many DUPs we
>compile in our source code:
>
>variable dup#
>:noname drop postpone dup 1 dup# +! ;
>: dup dup ; set-compiler
>
>It compiles correctly - tick
>it interprets correctly - tick
>what it compiles executes correctly - tick
>its tick compile and execute correctly, without or with little performance
>loss - tick
>[compile] works correctly - tick
>
>Anton's test: works on use 2 in OOP packages - tick
>
>Obviously it does work as Mitch Bradley expects it to work, and it even
>works as you expect it to work. Note that this dup here does not perform an
>optimization - it changes the compilation semantics of dup to *also*
>increment a counter at compile time.
No, it does not change the compilation semantics. It performs the
same compilation semantics, and adds instrumentation. And the
instrumentation you get with that is to count the number of times that
the xt of DUP is COMPILE,d.
>Using SET-COMPSEM results in a wrong number of counts with use 2 of that
>DUP, otherwise, it works fine, too.
It would count a different thing: How often the compilation semantics
of DUP is accessed. So it depends on what you want to access.
It would not work fine in all cases, however: [COMPILE] DUP would not
work properly, because SET-COMPSEM would make [COMPILE] think that DUP
has non-default compilation semantics, while it still has
(instrumented) default compilation semantics. If we wanted to be able
to instrument that, we would need a variant of SET-COMPSEM that marks
the word as still having default compilation semantics.
>> So you advocate leaving
>> the caveats away; that's certainly going to make teaching simpler,
>> it's just that the result will be more bugs.
>
>IMHO it's better to teach people about parsing words and recognizers, and
>why they should use recognizers instead of parsing words.
Yes.
>> You mean, just because I would no longer think about it that way, all
>> the use-2 uses of COMPILE, and the thoughts of their programmers would
>> go away?
>
>Only the corner-case use-2 with special compilation semantics, compile-only
>words and such stuff is changing. You are inflating the problem. These
>cases already don't work as people might assume right now in a number of
>systems
As long as we only have those few words, rarely a problem (and that
problem is covered in the standard by disallowing ticking these words).
But you suggest using SET-COMPILER instead of SET-COMPSEM not just for
these few words, but for defining words that might be used to define
many other words. I would not bet that nobody ever ticks the result
of such a defining word and never passes it to COMPILE,.
>> And even if it did, what about the future? Will no programmer ever
>> think again that he could speed his program up by using COMPILE,
>> instead of POSTPONE LITERAL POSTPONE EXECUTE?
>
>He usually can. It's a corner case where he can't. A corner case where it
>very likely won't work in many current Forth systems, either.
It certainly works for ordinary immediate words in all current Forth
systems.
>We can continue as we do now, and say this sort of stuff is simply not
>supposed to work portably. Or we say it's supposed to work in the next
>standard, and we then have to chose how. STATE-smart, SET-COMPILER or dual-
>xt are already implemented, and the three behave different.
I think the way to go for the standard is to leave them as-is and turn
them into legacy (and eventually obsolete) with recognizers. For a
system, the right thing to do is still deciding at parse/FIND time,
not later; the other solutions are good enough, though, as long as
their use is kept to a minimum.
>>>These problems are all holes of the needlessly complicated model of the
>>>current standard.
>>
>> Which problems?
>
>The standard tries to wrap around two (Forth-94) or three (Forth-2012)
>different ways to implement things. That's always complicating things.
>
>> 1) Incorrect shadowing is an implementation issue in dual-wordlist
>> systems and does not occur at all in other dual-xt systems.
>
>That doesn't remove other dual-xt problems.
What other problems?
>> 3) "' >R COMPILE," can be made to work without an optimizing COMPILE,,
>> as demonstrated by iForth-2.1.
>
>Hm, looks like iForth uses some sort of SET-COMPSEM to optimize? Is that
>the right approach?
I don't know what iForth actually uses. I would base optimization on
"COMPILE,", but basing it on compilation semantics is also possible
and does not lead to any problems except that you have to teach
[COMPILE] what is default compilation semantics and what is not; you
miss some (rare) optimization opportunities with that approach, however.
>> Your ' >R example shows that you do not need an optimizing COMPILE,.
>
>Sure, nobody needs an optimizer. But you might want one.
Sure, and hanging the optimizer on COMPILE, is fine; hanging special
compilation semantics on it is not.
>Your straw man is that COMPILE, would magically stop working on words with
>default compilation semantics.
No. My argument is that in the current standard the equivalence
between EXECUTE and COMPILE, holds for all xts you can get in a
standard program. If it doesn't, the system is non-standard. And it
does hold.
>If we want to make the behavior of use 2 portable across popular
>implementations, two out of three have to give in.
Nobody has to give in. It works already.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm
[toc] | [prev] | [next] | [standalone]
Page 14 of 17 — ← Prev page 1 … 12 13 [14] 15 16 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web