Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #47094 > unrolled thread
| Started by | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| First post | 2016-05-13 20:05 +0000 |
| Last post | 2016-05-17 21:08 +1000 |
| Articles | 20 on this page of 214 — 26 participants |
Back to article view | Back to comp.lang.forth
C to Forth (was Ting) stephen@mpeforth.com (Stephen Pelc) - 2016-05-13 20:05 +0000
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-13 14:06 -0700
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-14 00:27 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-13 21:55 -0700
RTX20xx ...Re: C to Forth (was Ting) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-05-19 08:58 +0100
Re: RTX20xx ...Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-21 04:08 -0400
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-21 04:09 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-13 14:33 -0700
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-14 00:28 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-13 21:02 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-14 15:15 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-14 17:39 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-14 16:56 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-14 20:25 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 00:16 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-15 00:19 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 08:58 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-15 08:24 -1000
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 17:18 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-15 18:52 -1000
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 06:23 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-16 15:12 -0700
Programmable "people" "WJ" <w_a_x_man@yahoo.com> - 2016-05-20 23:34 +0000
Re: Programmable "people" rickman <gnuarm@gmail.com> - 2016-05-21 00:48 -0400
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-23 14:21 +0000
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-15 10:42 +0000
Re: C to Forth (was Ting) "HAA" <someone@microsoft.com> - 2016-05-17 20:33 +1000
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-17 08:39 -0500
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-17 14:06 +0000
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-17 11:40 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 19:20 -0700
Re: C to Forth (was Ting) Tessa Bonting <tessa.bonting@gmail.com> - 2016-05-15 08:32 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-15 12:18 -0700
Re: C to Forth (was Ting) foxaudioresearch@gmail.com - 2016-05-25 13:41 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-15 17:22 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-15 17:24 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-15 19:30 -0700
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-16 13:37 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-16 07:25 -0700
Re: C to Forth (was Ting) Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-16 21:50 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-16 16:06 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-17 01:04 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 01:43 -0700
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-17 10:05 +0100
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 11:08 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-18 10:49 -0700
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-19 13:27 +0100
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-19 06:01 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-19 10:32 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 10:11 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-19 16:29 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 14:16 -0700
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-19 14:07 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 14:42 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-20 03:46 -0500
Re: C to Forth (was Ting) Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-05-20 04:53 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-20 22:16 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 21:43 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-21 15:56 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-21 02:52 -0500
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 22:11 -1000
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-21 03:13 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-21 15:43 -0700
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-22 22:22 -0700
Re: C to Forth (was Ting) Lars Brinkhoff <lars.spam@nocrew.org> - 2016-05-23 08:30 +0200
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 23:39 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 23:36 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-23 04:24 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 09:14 -0700
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-23 10:35 +0100
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-23 18:53 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-23 19:43 -1000
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 00:28 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-23 21:53 -1000
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 01:56 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 09:03 -0700
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-24 22:09 +0000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-23 22:59 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-24 04:32 -0500
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 12:46 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 15:26 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 15:57 -0700
Re: C to Forth (was Ting) Lars Brinkhoff <lars.spam@nocrew.org> - 2016-05-25 07:44 +0200
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-24 23:29 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-24 22:09 -1000
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-25 03:57 -0500
Re: C to Forth (was Ting) Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-05-24 11:04 +0100
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-24 14:01 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-19 15:05 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-19 21:25 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-20 03:57 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-20 06:48 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-20 09:40 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-20 09:31 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-20 13:53 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-20 14:16 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-21 03:01 -0500
Re: C to Forth (was Ting) Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-21 10:23 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-22 13:37 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-23 04:38 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-23 23:11 -0700
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-24 13:15 +0000
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-24 13:51 +0000
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 19:36 -0400
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-20 22:50 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-21 16:22 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-22 14:04 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 15:33 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-22 19:14 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-22 17:11 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-22 20:58 -0400
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-23 13:50 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-23 08:09 -0700
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-23 13:38 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-23 07:58 -0700
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-23 18:55 +0300
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-23 16:00 -0700
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-24 06:54 +0300
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 00:04 -0400
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-24 07:19 +0300
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 00:40 -0400
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-24 08:04 +0300
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-24 03:41 -0400
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-24 01:51 -0700
Re: C to Forth (was Ting) Bruce Axtens <bruce.axtens@gmail.com> - 2016-05-29 10:00 +0800
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-29 07:08 +0300
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-24 04:36 -0500
Re: C to Forth (was Ting) Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-05-24 02:48 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-23 19:28 -0500
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-23 11:46 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-23 13:30 -0400
Re: C to Forth (was Ting) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-24 13:37 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-25 14:22 -0700
Re: C to Forth (was Ting) Coos Haak <chforth@hccnet.nl> - 2016-05-26 00:29 +0200
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-25 16:12 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-25 23:29 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-26 14:06 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-25 19:30 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-25 20:52 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-25 23:27 -0400
Re: C to Forth (was Ting) Ron Aaron <rambamist@gmail.com> - 2016-05-26 07:40 +0300
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-26 10:03 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-26 14:31 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-27 07:22 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-27 06:07 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-27 10:00 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-27 15:51 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-27 16:27 -0700
Re: C to Forth (was Ting) Paul Rubin <no.email@nospam.invalid> - 2016-05-27 19:25 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-28 13:12 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-28 15:07 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-28 19:15 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-28 23:41 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-28 14:50 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-29 04:36 -0500
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-29 04:34 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-29 12:19 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-29 15:37 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-30 15:31 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-30 14:54 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-05-30 14:44 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-30 19:21 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-31 13:49 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-31 04:01 -0500
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-31 15:02 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-31 17:27 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-06-01 07:22 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-01 16:09 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-06-01 18:03 -1000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-02 06:36 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-01 02:54 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-06-01 08:50 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-06-01 07:38 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-06-01 10:58 -0400
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-01 11:32 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-06-01 17:10 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-01 17:04 -0700
Re: C to Forth (was Ting) "Elizabeth D. Rather" <erather@forth.com> - 2016-06-01 17:57 -1000
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-06-01 22:54 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-02 04:31 -0700
Re: C to Forth (was Ting) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-06-02 04:59 -0500
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-28 11:44 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-28 14:58 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-28 23:43 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-29 15:07 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-29 22:44 -0400
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-30 07:14 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-30 10:33 -0400
Re: C to Forth (was Ting) pahihu <pahihu@gmail.com> - 2016-05-30 10:31 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-30 16:57 -0400
Re: C to Forth (was Ting) pahihu <pahihu@gmail.com> - 2016-05-30 23:57 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-31 09:01 -0400
Re: C to Forth (was Ting) pahihu <pahihu@gmail.com> - 2016-05-31 07:17 -0700
Re: C to Forth (was Ting) humptydumpty <ouatubi@gmail.com> - 2016-05-30 13:12 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-30 14:09 -0700
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-06-01 10:07 +0000
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-06-01 17:13 -0700
Re: C to Forth (was Ting) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-05-17 02:14 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 11:50 -0700
Re: C to Forth (was Ting) Darin Murphy <murphy.darin@gmail.com> - 2016-05-17 15:28 -0700
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 18:52 -0700
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-18 09:41 -0400
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 01:12 -0700
Re: C to Forth (was Ting) Cecil Bayona <cbayona@cbayona.com> - 2016-05-17 04:34 -0500
Re: C to Forth (was Ting) hughaguilar96@gmail.com - 2016-05-17 10:46 -0700
Re: C to Forth (was Ting) Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-18 09:10 +0000
Re: C to Forth (was Ting) rickman <gnuarm@gmail.com> - 2016-05-18 09:36 -0400
Re: C to Forth (was Ting) Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-16 17:58 +0000
Cross compilers [Was: C to Forth] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 04:58 -0500
Re: Cross compilers [Was: C to Forth] Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> - 2016-05-18 11:25 +0000
Re: Cross compilers [Was: C to Forth] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-05-18 10:28 -0500
Recognizers (was: Cross compilers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-05-18 16:48 +0000
Re: C to Forth (was Ting) "WJ" <w_a_x_man@yahoo.com> - 2016-05-16 15:11 +0000
Re: C to Forth (was Ting) "HAA" <someone@microsoft.com> - 2016-05-17 21:08 +1000
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-24 15:26 -0700 |
| Message-ID | <f23f4d1b-8ced-4db6-864c-8935c0a1e731@googlegroups.com> |
| In reply to | #47486 |
On Tuesday, May 24, 2016 at 12:46:39 PM UTC-7, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > >> The approach I've been envisioning was to have a portable (all ANS) > >> compiler that produces bytecode for a simple VM. The VM could be > >> implemented (say in assembler) on any reasonable target... > > That all sounds rather indirect and complex. > > I don't see the complexity: a VM like that doesn't seem more complicated > than a traditional ITC address interpreter plus the usual bunch of CODE > primitives. The bytecode would be way more compact than ITC code, > especially with 32-bit cells. There could be a generic version of the > VM written in a few pages of straightforward C (basically a big switch > statement). That would allow porting the system to a new target with > very little effort if you can stand the VM overhead, if the target has a > C compiler. And yet, the VM would be separate from the main Forth > implementation, which would be written in Forth. Your suggestion of a standard VM is reasonable. I have a different suggestion though. I have my PAF16.TXT document that I'm going to release soon. Here is the abstract: PAF16 is a portable assembler for Forth for 16-bit processors. Different versions of PAF16 will assemble the same PAF16 program into code that can run on different processors. PAF16 doesn't have a machine-code of its own that is being emulated at run-time, so object-code is not portable (as is done in JAVA), but only source-code is portable (the PAF16 is for micro-controllers not consumer products so source-code will always be available; nobody is going to download apps for the PAF16). The PAF16 has 7 or 8 registers (16-bit) depending upon whether it is subroutine-threaded or direct-threaded (direct-threaded code uses less memory but requies an extra register for the IP). There is also a PAF16small that has yet one less register, but provides reduced support for quotations. The PAF16small is for micro-controllers with not much RAM and no need for data-structures (the PDP11 using direct-threading only supports PAF16small because it doesn't have enough registers for PAF16). ISRs are written in Forth. Typically the PAF16 instructions would compile into the machine-code of the target processor and the system would be subroutine-threaded, but it is possible for the PAF16 instructions to compile into a VM being emulated on the target processor and the system would be indirect-threaded, direct-threaded (i8086 or PDP11) or token-threaded (AVR). The PAF16 defines behavior, not implementation, so various threading schemes can be used internally. The idea is that anybody writing a Forth compiler can target the PAF16 rather than any specific processor and his Forth will work for any processor so long as there is a PAF16 assembler available that generates machine-code for that processor. The Forth compiler-writer has latitude in regard to what features his Forth will provide, and these Forth systems won't necessarily be compatible. Also, anybody who is writing HDL for an FPGA processor can get any PAF16-based Forth system to work with his processor so long as he provides a PAF16 assembler that generates executable code for his processor. The FPGA designer has latitude in regard to what features his processor will provide, and these processors' machine-code won't necessarily be compatible. On the PIC24 we have eight unused registers, so the PIC24 is not being used to its full potential by PAF16, but that is okay because the goal of PAF16 is portability of programs between different processors --- if PAF16 took full advantage of the PIC24, then programs would not be portable to smaller processors (everything is smaller than the PIC24).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-24 15:57 -0700 |
| Message-ID | <a69183d5-a24b-4697-86e0-b519c11e0127@googlegroups.com> |
| In reply to | #47490 |
On Tuesday, May 24, 2016 at 3:26:53 PM UTC-7, hughag...@gmail.com wrote: > I have my PAF16.TXT document that I'm going to release soon. Here is another excerpt: In the case of the i8086, PAF16 is a pretty close match. In the case of the PIC24, PAF16 is not using the processor to its full potential (there are 8 unused registers) --- the goal of PAF16 is portability, so it can't use the PIC24 to its full potential or it won't work on smaller processors with fewer registers (the PIC24 has 20 registers, and there are no other 16-bit processors with that many registers). On a powerful processor such as the PIC24, there is a way to have portability, but to also take full advantage of the powerful processor. A code-library can have two versions, one written in PAF16 Forth and the other written in PIC24 assembly-language. The latter version, because it uses all the registers, will presumably be faster than the former version that uses only the PAF16 subset. Although the user's own code will necessarily be PAF16 and use the subset, the user's program should be reasonably fast, especially if the code-library in question is something critical (a floating-point package, in a program that does a lot of floating-point calculation, or a USB device-driver in a program that does a lot of com). The idea is to isolate the non-portable parts of the program --- if the code-library written in PAF16 isn't fast enough on another processor (such as the MSP-430), then the code-library can be ported to the assembly-language of that processor --- only the non-portable parts have to be ported manually, rather than the entire program. When moving to a processor such as the i8086, the version of the code-library written in PAF16 Forth should be almost as fast as a version written in i8086 assembly-language because the PAF16 is a close match to the i8086. It is assumed that most micro-controllers are going to be 16-bit, which is why PAF16 specifies 16-bit registers. The small 16-bit processors are a lot faster than the big 32-bit processors because they have all of their RAM on-chip. For the most part, being fast and having a lot of RAM are mutually exclusive features. The 32-bit processors are not only slow, but they are expensive --- off-chip RAM implies a multi-chip board, whereas on-chip RAM implies a single-chip board. Of course, the desktop-computer processors are both fast and have a lot of RAM --- they accomplish this by having an on-chip RAM cache (a 32KB cache in the 64-bit x86) --- this has been done in micro-controllers also, but tends to be expensive. There are also 32-bit processors (versions of the ARM Cortex) that have a small amount of RAM and are fast because the RAM is on-chip --- a 32-bit processor is inefficient in regard to RAM usage though because 32-bit data takes up twice as much memory as 16-bit data --- it is very rare however that 32-bit data is actually needed (ADC and DAC ports continue to be 12-bit or 16-bit, same as 20 years ago).
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-05-25 07:44 +0200 |
| Message-ID | <86lh2yheu4.fsf@molnjunk.nocrew.org> |
| In reply to | #47486 |
Paul Rubin <no.email@nospam.invalid> writes: >>> There's also the whole need to juggle the target wordlist >> That one isn't a problem: when cross-compiling you'd arrange for some >> command which sets the search order as appropriate. > You're saying that the existing facilities let you accomplish the task > if you're willing to do enough contortions. You seem to believe that using wordlists in a cross compiler would be painful. Why is that? This is not a rhetorical question. I have made several attempts at writing a cross compiler in Forth. I had a few vague ideas of my own about how to do it. The first was a failure, and I didn't finish it. The second was a mess, but it worked. Then I read a few Forth Dimensions articles about metacompilation. I decided to forget about my own ideas, and follow the advice of the more experienced Forthers. I'd like to think my third cross compiler was a considerable improvement. One of the things I read about, and followed closely in my own implementation, was using wordlists in a cross compiler. It seems to me a natural fit, rather than a painful contortion.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-24 23:29 -0700 |
| Message-ID | <7fbfc77d-7f51-45a2-a47b-308865201932@googlegroups.com> |
| In reply to | #47494 |
On Tuesday, May 24, 2016 at 10:44:04 PM UTC-7, Lars Brinkhoff wrote: > Paul Rubin <no.email@nospam.invalid> writes: > >>> There's also the whole need to juggle the target wordlist > >> That one isn't a problem: when cross-compiling you'd arrange for some > >> command which sets the search order as appropriate. > > You're saying that the existing facilities let you accomplish the task > > if you're willing to do enough contortions. > > You seem to believe that using wordlists in a cross compiler would be > painful. Why is that? This is not a rhetorical question. > > I have made several attempts at writing a cross compiler in Forth. > I had a few vague ideas of my own about how to do it. The first was a > failure, and I didn't finish it. The second was a mess, but it worked. > > Then I read a few Forth Dimensions articles about metacompilation. > I decided to forget about my own ideas, and follow the advice of the > more experienced Forthers. I'd like to think my third cross compiler > was a considerable improvement. > > One of the things I read about, and followed closely in my own > implementation, was using wordlists in a cross compiler. It seems to me > a natural fit, rather than a painful contortion. I have written a cross-compiler in both Forth-83 (MFX) and ANS-Forth. I had to fix ANS-Forth before it could be used --- this fix is in the novice-package now --- I have PUSH-CONTEXT POP-CONTEXT GET-CONTEXT SET-CONTEXT PUSH-UNDERNEATH REPLACE-1ST (all of this works correctly in the sense that it doesn't result in duplicate wids in the wid-stack).
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-05-24 22:09 -1000 |
| Message-ID | <CbGdnSsFFu5PwNjKnZ2dnUU7-dfNnZ2d@supernews.com> |
| In reply to | #47494 |
On 5/24/16 7:44 PM, Lars Brinkhoff wrote: > Paul Rubin <no.email@nospam.invalid> writes: >>>> There's also the whole need to juggle the target wordlist >>> That one isn't a problem: when cross-compiling you'd arrange for some >>> command which sets the search order as appropriate. >> You're saying that the existing facilities let you accomplish the task >> if you're willing to do enough contortions. > > You seem to believe that using wordlists in a cross compiler would be > painful. Why is that? This is not a rhetorical question. > > I have made several attempts at writing a cross compiler in Forth. > I had a few vague ideas of my own about how to do it. The first was a > failure, and I didn't finish it. The second was a mess, but it worked. > > Then I read a few Forth Dimensions articles about metacompilation. > I decided to forget about my own ideas, and follow the advice of the > more experienced Forthers. I'd like to think my third cross compiler > was a considerable improvement. > > One of the things I read about, and followed closely in my own > implementation, was using wordlists in a cross compiler. It seems to me > a natural fit, rather than a painful contortion. It is a natural fit. It's actually very simple. There are a very few situations that occur during this process, and each has a logical configuration of wordlists. They are described in the proposed cross-compiler standard: * ASSEMBLER: Words executed on the host while compiling assembler definitions for the target. Typically, they provide machine code instructions and addressing modes. Examples: MOV PUL JMP * HOST Words in the host system that provide support for the cross-compiler and debugging. Typical search order: FORTH FORTH FORTH Examples: LOGGING VERBOSE * INTERPRETER Words executed on the host while interpreting on behalf of the target. Typically, they set up data structures, allocate memory, or start compilation. Typical search order: *Interpreter FORTH *INTERPRETER Examples: CONSTANT ALLOT : * COMPILER Words used on the host while compiling target structures. Typical search order: *Compiler FORTH FORTH Examples: IF CASE ; LITERAL * TARGET Words compiled onto the target, to be executed by target programs. (The default scope.) Typical search order: *TARGET *INTERPRETER *COMPILER Examples: DUP + ! The names beginning with * are special to the target compiler. Once you understand the design, it's really pretty simple. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-25 03:57 -0500 |
| Message-ID | <AYidncdp1I9x9djKnZ2dnUU7-dfNnZ2d@supernews.com> |
| In reply to | #47486 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> The approach I've been envisioning was to have a portable (all ANS) >>> compiler that produces bytecode for a simple VM. The VM could be >>> implemented (say in assembler) on any reasonable target... >> That all sounds rather indirect and complex. > > I don't see the complexity: a VM like that doesn't seem more > complicated than a traditional ITC address interpreter plus the > usual bunch of CODE primitives. The bytecode would be way more > compact than ITC code, especially with 32-bit cells. Oh, sure, but it's not going to be very fast. I thought you were suggesting another level of translation. Traditionally (and IMO correctly) you define a real cross-compiler (and -assembler) which lay down code for the target. That's a model that I'm so familiar with and works so well that I dont understand why anyone would seek an alternative. >>> create a dictionary [word] from a string >> That's not really useful because there are many different kinds of >> words: VARIABLEs, colon definitions, CREATED words, etc. > > I imagine allocating a chunk of memory as the target dictionary, using > DEFINE to insert a few primitives in it, then self-host What do you mean by self-host? > the other words the usual way, defining VARIABLE using CREATE etc. > I think eForth works like that. Sure, but you're defining words to run on the target, not the host. On the host, you have to create words which point into the target's address space. >>> There's also the whole need to juggle the target wordlist >> That one isn't a problem: when cross-compiling you'd arrange for some >> command which sets the search order as appropriate. > > You're saying that the existing facilities let you accomplish the task > if you're willing to do enough contortions. Not at all: I'm saying that vocabularies (AKA wordlists) have been used for this particular job since the year dot, and are ideal for the purpose. And -- of course -- I am unaware of whatever contortions you have in mind. So I can't say what would be better. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-05-24 11:04 +0100 |
| Message-ID | <ni18nl$ci1$1@dont-email.me> |
| In reply to | #47454 |
On 24/05/2016 02:53, Paul Rubin wrote: > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes: >> The harder case is where the target is different >> (e.g. any of a different CPU, type of threading, dictionary structure >> etc) when target code can't be executed. Here wordlists are very >> helpful if not essential, as is another outer interpreter. > > I'll have to think about this more. The approach I've been envisioning > was to have a portable (all ANS) compiler that produces bytecode for a > simple VM. The VM could be implemented (say in assembler) on any > reasonable target and run the bytecode. The compiler would of course > itself be able to compile itself into bytecode, making the jump from > host to target that way. Then the bytecode backend could be replaced > with a native STC generator for the relevant platform. Yes that's certainly possible but it depends on the format of your byte code. If you represent, say, the call to a definition with a byte code followed by the name of the definition as a text string then you don't need to look up the word in the target dictionary when cross compiling. But then the target code generator is harder. If you want a reference to it you do need to look it up. Also as Andrew pointed out there is the difficulty if you have any target words defined by CREATE ... DOES> ... > >> I don't think the wordlist contributed to any ugliness, that is due to >> the fact that ANS Forth has no direct way of defining a word without >> parsing a name. > > I'd consider that absence to be a deficiency of ANS wordlists. ANS wordlists? I'd call it a deficiency of ANS Forth. I think various people have requested this over the years and that is why Anton created EXECUTE-PARSING which is implemented using standard words. > ANS has > FIND (looks up a string given in c-addr form) but no way to do the > opposite (create a dictionary from a string, maybe it could be called > DEFINE unless there's already a conventional name for such a word in > implementations that have it). > > There's also the whole need to juggle the target wordlist into the > "current wordlist" position instead of having FIND and DEFINE simply > take a wid argument. > Is this about the cross-compiler or wordlists in general. If the cross compiler you just define words called, say, HOST and TARGET, that do the juggling for you. I guess FIND not taking a wid is simply a legacy thing. The basic definition primitive DEFINE could take (caddr u wid) as arguments then it is easy to define :NAME (caddr u ) to go into the current wordlist and : that parses and calls :NAME but that leads to a proliferation of words as the same thing would be needed for other definers VARIABLE 2VARIABLE CONSTANT 2CONSTANT VALUE 2VALUE CREATE. EXECUTE-PARSING can be used for all these - perhaps it should take a wid but perhaps not as it has uses beyond creating definitions. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-05-24 14:01 +0000 |
| Message-ID | <2016May24.160133@mips.complang.tuwien.ac.at> |
| In reply to | #47454 |
Paul Rubin <no.email@nospam.invalid> writes:
>ANS has
>FIND (looks up a string given in c-addr form) but no way to do the
>opposite (create a dictionary from a string, maybe it could be called
>DEFINE unless there's already a conventional name for such a word in
>implementations that have it).
Yes, that's the weakness of all parsing words, worked around with
EXECUTE-PARSING.
>There's also the whole need to juggle the target wordlist into the
>"current wordlist" position instead of having FIND and DEFINE simply
>take a wid argument.
FIND searches the whole search order. What you are thinking of is
SEARCH-WORDLIST ( c-addr u wid -- 0 | xt 1 | xt -1 ), which actually
takes a wid from the stack.
Concerning the current wordlist for definitions, there is only one
such wordlist, that you set with SET-CURRENT, and can preserve with
GET-CURRENT ... SET-CURRENT, no juggling involved. Admittedly this
pair of words is still not the most convenient, and for the things you
have in mind I would add
: current-execute ( ... wid xt -- ... )
get-current >r swap set-current catch r> set-current throw ;
If you then want to CREATE a word with the name and wid coming from
the stack, you can do it with
s" name" my-wordlist ' create ' execute-parsing current-execute
- 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 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-05-19 15:05 -0700 |
| Message-ID | <5f27b572-5256-4b96-9cc0-206ed7abc96a@googlegroups.com> |
| In reply to | #47310 |
> > Why do we need to rewrite an entire interpreter, when > > cross-compilation requires well-defined and limited features? > > Because it's the best way to do it. The "entire interpreter" is a > small piece of code, and it makes sense to write one which is extended > to include cross compilation. You're pretending to choke on a gnat. The best way is to replace only one word, or add a word to execute before or after existing. I don't plan to do exercises every time I want to write a practical code. What if my new interpreter will broke a code added by previous loaded libraries? This is annoying and I don't want to waste my time writing 'pure Forth-style code'. > This is Forth! We have the choice of putting a bunch of hooks in the Does this mean you possesses the 'Spirit of Forth'? :) > There's no-one better than Chuck Moore on this: "Do not leave hooks on > which you can hang extensions. The things you might want to do are > infinite; that means that each has 0 probability of realization. If > you need an extension later, you can code it later -- and probably do > a better job than if you did it now. And if someone else adds the > extension, will he notice the hooks you left?" Ok, I need this extension. What now? I also need a pack of vectored words, analyzing functional keys, mouse events and timers while user entering text in Forth console. This is another example of non-ANS behavior, caused many flames in RuFIG. Several peoples tried to 'explain' me this way is wrong and new version of message dispatcher can be easily written if needed. But why I must keep only basic version, if I need these features for almost every program? I can assign a word to K_F1 and simple press F1 to run this word. Just several critical points must be vectorized to greatly improves usability of Forth engine. If you think Moore will come to blame me... 1) I'm not sure he will 2) why do you think my interest to Forth made me depended on any kind of guru? Peoples make mistakes, and followers may interpret right thesises by wrong way. So let's call Moore and ask if you want to point to him ;)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-19 21:25 -0700 |
| Message-ID | <c653b718-c651-47d9-ac97-8e9712ff3667@googlegroups.com> |
| In reply to | #47330 |
On Thursday, May 19, 2016 at 3:05:30 PM UTC-7, Ilya Tarasov wrote: > Peoples make mistakes, and followers may interpret right thesises by wrong way. So let's call Moore and ask if you want to point to him ;) If we assume that Charles Moore was a genius (a good argument can be made that he was), then we have to also assume that his thinking was complex and nuanced --- this implies that simple-minded platitudes representing him are certainly incorrect. Elizabeth Rather has spent her entire career doing everything in her power to prevent general-purpose data-structures from being written in Forth, all on the basis that this is what Charles Moore desired. Here are some typical quotes: "...in Forth it's so easy to build data structures that are exactly right for the particular application at hand that worrying about what pre-built structures you have and how to use them is just not worth the bother." "...in applications where you *do* want to do range checking [of array indices], you may not always want to do the same thing. In some cases, you want to give an error message, in others you want to clip or substitute for the errant value or take some completely different action. The programmer should have full control." "Virtually every Forth application needs some kind of array structures. The reason that some general-purpose one might be 'little used' is because it's so easy to make a version that does *exactly* what the application needs rather than some generic definition. ... The objective is to master the toolset and be able to think clearly about exactly what kind of arrays will be useful in your application and then build exactly that kind." This is making the whole subject overly complicated. A general-purpose array is fine --- there is no need to customize the array for each application program --- also, all of her quotes are about arrays because that is the only data-structure that she knows about (arrays were the only data-structure discussed in "Starting Forth"); she doesn't actually know that there are other data-structures, such as lists and trees etc.. It seems very unlikely that Charles Moore spent a lot of time customizing the perfect array for each application program that he wrote. Who has time for that? More likely, he was okay with general-purpose code --- he just didn't have time to write any code libraries before he got kicked out of Forth Inc. (he got kicked out in 1982, which was only 3 years after the Forth-79 standard was written, which was the first attempt at standardization). I don't think Elizabeth Rather has the authority to declare that I'm not a Forth programmer because I write general-purpose data-structures in Forth. It seems very unlikely that Charles Moore would support her in this. It also seems very unlikely that Charles Moore cares one way or the other --- if he did, he would come to c.l.f. and say so --- but he doesn't. Elizabeth Rather is not channeling Charles Moore --- general-purpose data-structures are just her own bugaboo --- Charles Moore doesn't actually care. P.S. Why do all the ANS-Forth cult members refer to Charles Moore as "Chuck"? They are pretending that he is their buddy that they are on a first-name basis with. Bullshit! He doesn't even know who you are, nor does he care, same as with myself.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-20 03:57 -0500 |
| Message-ID | <fdCdnZdZrM0ITKPKnZ2dnUU7-Y3NnZ2d@supernews.com> |
| In reply to | #47330 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > Why do we need to rewrite an entire interpreter, when >> > cross-compilation requires well-defined and limited features? >> >> Because it's the best way to do it. The "entire interpreter" is a >> small piece of code, and it makes sense to write one which is extended >> to include cross compilation. You're pretending to choke on a gnat. > > The best way is to replace only one word, or add a word to execute > before or after existing. I don't plan to do exercises every time I > want to write a practical code. What if my new interpreter will > broke a code added by previous loaded libraries? This is annoying > and I don't want to waste my time writing 'pure Forth-style code'. So what? It's no big deal; it's not difficult; and it's an absolutely minuscule part of the effort required to write a cross-compiler. IMO: words in the standard should be those needed to write applications because it's impractical, impossible, or inefficient to provide them as libraries. That's the only way to keep the standard reasonably small. >> This is Forth! We have the choice of putting a bunch of hooks in the > > Does this mean you possesses the 'Spirit of Forth'? :) I hope so! >> There's no-one better than Chuck Moore on this: "Do not leave hooks on >> which you can hang extensions. The things you might want to do are >> infinite; that means that each has 0 probability of realization. If >> you need an extension later, you can code it later -- and probably do >> a better job than if you did it now. And if someone else adds the >> extension, will he notice the hooks you left?" > > OK, I need this extension. What now? I also need a pack of vectored > words, analyzing functional keys, mouse events and timers while user > entering text in Forth console. Gosh. Each to their own, I guess. > This is another example of non-ANS behavior, caused many flames in > RuFIG. I don't understand how this is non-ANS. There doesn't seem to be any conflict. > Several peoples tried to 'explain' me this way is wrong and new > version of message dispatcher can be easily written if needed. But > why I must keep only basic version, if I need these features for > almost every program? I can assign a word to K_F1 and simple press > F1 to run this word. Just several critical points must be vectorized > to greatly improves usability of Forth engine. If you think Moore > will come to blame me... 1) I'm not sure he will 2) why do you think > my interest to Forth made me depended on any kind of guru? I didn't quote Chuck because he was some kind of guru, but because he expressed this idea very well. I could have paraphrased it in my own words, but what would be the point? And once you use someone else's words, you must give credit, so I did. > Peoples make mistakes, and followers may interpret right thesises by > wrong way. So let's call Moore and ask if you want to point to him > ;) About what? Whatever your Forth will do, enjoy it. People like Chuck can only advise. When that advice is given it falls on the ear of the recipient, and then it's gone. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-05-20 06:48 -0700 |
| Message-ID | <d2a3b3f4-8c55-469b-9d39-6489066c84ab@googlegroups.com> |
| In reply to | #47336 |
> > The best way is to replace only one word, or add a word to execute > > before or after existing. I don't plan to do exercises every time I > > want to write a practical code. What if my new interpreter will > > broke a code added by previous loaded libraries? This is annoying > > and I don't want to waste my time writing 'pure Forth-style code'. > > So what? It's no big deal; it's not difficult; and it's an absolutely > minuscule part of the effort required to write a cross-compiler. Can't you see in this case you simple use Forth interpreter once to run another interpreter? Also I don't understand why I must so care about limiting my Forth by someone's opinion, if I use the same mechanism ten times and want to see it built-in? > IMO: words in the standard should be those needed to write > applications because it's impractical, impossible, or inefficient to > provide them as libraries. That's the only way to keep the standard > reasonably small. One of big problem is concentrated around vectorized words. There are many reasons to have some words inside interpreter vectorized, but over 20 years ANS apologets don't want to listen anything about it :) Making LITERAL vectorized is very easy. I see no reasons for me to return back to ANS version of interpreter, because it breaks almost all my programs. > >> This is Forth! We have the choice of putting a bunch of hooks in the > > > > Does this mean you possesses the 'Spirit of Forth'? :) > > I hope so! So do you think you are right because you possesses this 'Spirit' while I'm not? :) > > OK, I need this extension. What now? I also need a pack of vectored > > words, analyzing functional keys, mouse events and timers while user > > entering text in Forth console. > > Gosh. Each to their own, I guess. Ok, I have it (let me remember) since 1995 or 1996. A large list of vectorized words inside Forth engine and many effective ways to use it. Also many questions 'why do you write is this way?', 'when do you plan to implement it accordingly to ANS?' and even 'when you will accept the Spirit of Forth?' :) > > This is another example of non-ANS behavior, caused many flames in > > RuFIG. > > I don't understand how this is non-ANS. There doesn't seem to be any > conflict. Ok, explain it to those, who triyng to prevent any extensions. > > Peoples make mistakes, and followers may interpret right thesises by > > wrong way. So let's call Moore and ask if you want to point to him > > ;) > > About what? Whatever your Forth will do, enjoy it. Of course, Im very happy with my Forths and Forth-CPUs. I just can see there is another iteration of wasting time for peoples who don't want to take a look on their activity from the distance. Ok, another little club for chosen persons, 'who possesses the Spirit of Forth' and interpreting this by their own style. When I ask some peoples, how they use Forth now and what projects they complete last year, they name me a troll! :) So I clearly see they can't achieve any valuable result with their ANS-compatible products, but pretends to teach everyone around. > People like Chuck can only advise. When that advice is given it falls > on the ear of the recipient, and then it's gone. Any advices are welcome. But nobody should accept advice 'as is'. I told you I need some of these hooks for practical purposes, but are you think I'm still wrong?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-20 09:40 -0500 |
| Message-ID | <2sCdnfHz_sZIvKLKnZ2dnUU7-T3NnZ2d@supernews.com> |
| In reply to | #47343 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > The best way is to replace only one word, or add a word to execute >> > before or after existing. I don't plan to do exercises every time I >> > want to write a practical code. What if my new interpreter will >> > broke a code added by previous loaded libraries? This is annoying >> > and I don't want to waste my time writing 'pure Forth-style code'. >> >> So what? It's no big deal; it's not difficult; and it's an absolutely >> minuscule part of the effort required to write a cross-compiler. > > Can't you see in this case you simple use Forth interpreter once to > run another interpreter? Yes. > Also I don't understand why I must so care about limiting my Forth > by someone's opinion, if I use the same mechanism ten times and want > to see it built-in? It's your Forth, so do what you like. The only interesting question for me is what should be standard. >> IMO: words in the standard should be those needed to write >> applications because it's impractical, impossible, or inefficient to >> provide them as libraries. That's the only way to keep the standard >> reasonably small. > > One of big problem is concentrated around vectorized words. There > are many reasons to have some words inside interpreter vectorized, > but over 20 years ANS apologets don't want to listen anything about > it :) Making LITERAL vectorized is very easy. I see no reasons for > me to return back to ANS version of interpreter, because it breaks > almost all my programs. I've always liked vectorized NUMBER. As far as I can remember every Forth I've ever used supports it. Recognizers are one way to do achieve the same thing, but I don't like the latest proposal because it seems to me to go too far. >> >> This is Forth! We have the choice of putting a bunch of hooks >> >> in the >> > >> > Does this mean you possesses the 'Spirit of Forth'? :) >> >> I hope so! > > So do you think you are right because you possesses this 'Spirit' > while I'm not? :) I don't know about you, but I certainly hope I do. Every language has an ethos, especially unusual languages like, say, Forth, Haskell, and LISP. In any of these languages one can program in a "conventional" way, but the results won't be great. (As the old saying, goes "The determined Real Programmer can write FORTRAN programs in any language.") Without using Forth design (as described in e.g. Thinking FORTH and Programming a Problem-Oriented Language) FORTH can be an just annoying nuisance. All this SWAP DROP ROT blah. But use Forth in the way that it was intended and the results can be elagant and sparkling. Of course there are no guarantees, and in the end no substitute for good taste. >> > This is another example of non-ANS behavior, caused many flames in >> > RuFIG. >> >> I don't understand how this is non-ANS. There doesn't seem to be any >> conflict. > > Ok, explain it to those, who triyng to prevent any extensions. That's not my job! Everything you describe sounds fine and ANS-compatible to me. >> People like Chuck can only advise. When that advice is given it falls >> on the ear of the recipient, and then it's gone. > > Any advices are welcome. But nobody should accept advice 'as is'. I > told you I need some of these hooks for practical purposes, but are > you think I'm still wrong? No. I think you're misunderstanding what Chuck wrote. If you actually *use* a hook, then the probability of it being used is 1, not 0. Chuck was talking about *speculative* hooks, and there is a huge difference. Andrew. [1] www.forth.org/POL.pdf
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-20 09:31 -0700 |
| Message-ID | <631adf78-6175-4d5b-b6fb-63b01f98eb96@googlegroups.com> |
| In reply to | #47346 |
On Friday, May 20, 2016 at 7:40:22 AM UTC-7, Andrew Haley wrote: > Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: > > Also I don't understand why I must so care about limiting my Forth > > by someone's opinion, if I use the same mechanism ten times and want > > to see it built-in? > > It's your Forth, so do what you like. The only interesting question > for me is what should be standard. This really summarizes everything that Andrew Haley has to say, or ever will have to say. So long as Andrew Haley brown-noses Elizabeth Rather then he is Standard with a capital 'S' and he can dismiss everything that programmers such as Ilya do simply by saying that it is non-standard and hence meaningless --- he doesn't even have to understand the subject being discussed (he doesn't actually understand how cross-compilers work) --- he can use the mighty Standard club to squash everybody left and right, to win every debate with ease, until nobody dares to write a line of Forth code without his permission. What will actually happen is that Ilya will give up comp.lang.forth as a waste of time and his FPGA Forth processor will be unknown, but Bernd Paysan's B16 will be the only FPGA Forth processor that anybody ever hears about. Of course, the B16 isn't ANS-Forth compatible either, but Bernd brown-noses Elizabeth Rather faithfully, and Elizabeth Rather appointed Bernd to the Forth-200x committee, so this doesn't matter --- ANS-Forth is a cult so being ANS-Forth is all about loyalty but has nothing to do with compatibility. All of these threads end up being deja-vu all over again. Previously Andrew Haley used the term "Forth Way" and now he uses the term "Forth Spirit," but other than that it is the same argument every time: https://groups.google.com/forum/#!searchin/comp.lang.forth/uart%7Csort:date/comp.lang.forth/pqhqqvWg9zk/vpBKfGHsDwAJ On Friday, April 29, 2016 at 12:11:42 AM UTC-7, hughag...@gmail.com wrote: > On Tuesday, April 26, 2016 at 2:04:29 AM UTC-7, Andrew Haley wrote: > > Paul Rubin <no.email@nospam.invalid> wrote: > > > Maybe if I know the application only uses half-duplex, I can > > > implement some hacky thing that relies on that fact. But if I'm > > > supplying a library facility it wouldn't occur to me to limit it > > > like that. > > > > I'm sure it wouldn't, because you don't really think in the Forth way. > > Don't speculate! > > ANS-Forth is a cult --- this is why we have Andrew Haley's emphasis on the "Forth Way." Andrew Haley is supporting Elizabeth Rather by arguing against full-duplex asynchronous communication, despite the fact that the UART has been in use since the 1970s and is generally considered to be one of the big breakthroughs of computer science --- no matter how stupid Elizabeth Rather's pronouncements are, the cult members will argue in favor of those pronouncements using twisted logic and blatant lies. > > Elizabeth Rather says: "I can't think offhand of a case in which a > full-duplex port literally has concurrent streams of data flowing in and > out." She is opposed to general-purpose code and instead wants hacky code that relies on the fact that a particular application only needs half-duplex code --- but this code won't work on other applications that need full-duplex, so it is not general-purpose. > > Why is general-purpose code considered to be in contradiction to the "Forth Way"? I've seen a handful of quotes from Charles Moore indicating that he is opposed to general-purpose code. I don't think this proves that he is opposed to general-purpose code though; this reminds me of how people find a handful of quotes in the Bible that support their agenda, and they ignore the huge number of quotes that are in contradiction to their agenda. If Charles Moore really was opposed to general-purpose code he would be on comp.lang.forth denouncing general-purpose code, and he would also be on comp.lang.forth agreeing with Elizabeth Rather than I'm not a Forth programmer --- but he isn't. > > Most likely, what happened is that sometime in the 1970s Charles Moore made a comment to Elizabeth Rather such as: "I don't have time to write a general-purpose code-library because I told the customer that I would have the program ready on Monday, so I'm just going to hack together some code over the weekend." This little bit of wisdom stuck in Elizabeth Rather's mind forever, and so she spent the rest of her life denouncing general-purpose code-libraries in favor of hacky application-specific code that can't be reused. > > Another problem here is that Elizabeth Rather just doesn't understand how general-purpose code is possible. This is what she said about my general-purpose data-structures in my novice package: > -------------------------------------------------------------------------- > Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure. > -------------------------------------------------------------------------- > That's stupid! But ANS-Forth is a cult, so all the cult members totally support Elizabeth Rather on this. > > I would like to meet Charles Moore someday, just to ask him if he is really opposed to general-purpose code-libraries, and if he agrees with Elizabeth Rather that I'm not a Forth programmer. I suspect that he doesn't support ANS-Forth and he is okay with me writing code in Forth --- but you never know --- maybe he totally supports ANS-Forth and he damns me to Hell for having written MFX for the MiniForth.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-05-20 13:53 -0400 |
| Message-ID | <nhnio5$mc3$3@dont-email.me> |
| In reply to | #47349 |
Hugh doesn't seem to be winding down this time. I guess there is something upsetting him in his personal life and he is venting here. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-05-20 14:16 -0700 |
| Message-ID | <6ae7eb3d-fdc0-4051-a2a9-55665b3e7bda@googlegroups.com> |
| In reply to | #47346 |
> > Can't you see in this case you simple use Forth interpreter once to > > run another interpreter? > > Yes. On this way you can simple run MS Visual Studio from your Forth. > It's your Forth, so do what you like. The only interesting question > for me is what should be standard. I know this is my Forth. Interesing question from me - what is standard goals? With no goal declared this is no chance to decide use it ir not. I don't know where ANS-Forth going and can't be sure it is going in right direction. > > So do you think you are right because you possesses this 'Spirit' > > while I'm not? :) > > I don't know about you, but I certainly hope I do. > Every language has an ethos, especially unusual languages like, say, > Forth, Haskell, and LISP. In any of these languages one can program > in a "conventional" way, but the results won't be great. (As the old > saying, goes "The determined Real Programmer can write FORTRAN > programs in any language.") Unfortunately, small and uncommon community often leads to 'white crow syndrome'. An idiomaic-precise translation is close to 'divergent', but has more deep meaning un Russian. Crows are black, so white crow is uncommon. Moreover, white crow constantly trying to focus others on its difference and use it as a feature. 'Forth-way' or, translated from Russian FIG, 'Spirit of Forth' is an easy way to stop any discussion and claim yourself as a winner. > Without using Forth design (as described in e.g. Thinking FORTH and > Programming a Problem-Oriented Language) FORTH can be an just annoying > nuisance. All this SWAP DROP ROT blah. But use Forth in the way that > it was intended and the results can be elagant and sparkling. Of > course there are no guarantees, and in the end no substitute for good > taste. I have a lot of examples where Forth was used properly, not by me only. I prefer to listen colleagues and add features they want, whenever it ANS-compatible or not. ANS is far from me and I have no projects or contract proposals based on ANS compatibility. My company is... my company :) I need some features to implement and don't want wait until someone comes to agrees me. So someone just lost me as a customer. > That's not my job! Everything you describe sounds fine and > ANS-compatible to me. I don't see any serious troubles too. Why main loop in Forth must be untouchable? You told it sound fine, but other peoples may tell this is non-standard behavior and I must write another interpreter to add words or features. For example, having floating point was absolutely critical for me 20 years ago. This was easily done with vecorized NUMBER and LITERAL in SP-Forth. When I ask Andrey Cherezov for some changes to his SP-Forth (LITERAL was non-vectorized) he answer... right! 'This is non-standard, everyone may be happy with integer numbers or fixed point'. How do you think, is it prevents me from rewriting Forth according to my design? > No. I think you're misunderstanding what Chuck wrote. If you > actually *use* a hook, then the probability of it being used is 1, not > 0. Chuck was talking about *speculative* hooks, and there is a huge > difference. But I point you to real used things, not to hooks for future use by someone. LITERAL is required. EMIT is very useful. DISPATCH-NUMBER was used by me yesterday to convert several files with numbers in text format. Reaction of ANS committee is more intresting thing. Why don't add useful things, if programmers want to see it? Oh, I see, this is dangerous because will lead to real projects and paid job ;)
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-21 03:01 -0500 |
| Message-ID | <Zb6dnU0GGaBLiN3KnZ2dnUU7-aXNnZ2d@supernews.com> |
| In reply to | #47368 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> > Can't you see in this case you simple use Forth interpreter once to >> > run another interpreter? >> >> Yes. > > On this way you can simple run MS Visual Studio from your Forth. Probably, but what for? >> It's your Forth, so do what you like. The only interesting question >> for me is what should be standard. > > I know this is my Forth. Interesing question from me - what is > standard goals? With no goal declared this is no chance to decide > use it ir not. I don't know where ANS-Forth going and can't be sure > it is going in right direction. There are two goals: common libraries and a common language. Without some common understaning about what Forth is, we can't even talk about Forth programs. >> No. I think you're misunderstanding what Chuck wrote. If you >> actually *use* a hook, then the probability of it being used is 1, not >> 0. Chuck was talking about *speculative* hooks, and there is a huge >> difference. > > But I point you to real used things, not to hooks for future use by > someone. LITERAL is required. EMIT is very useful. DISPATCH-NUMBER > was used by me yesterday to convert several files with numbers in > text format. Reaction of ANS committee is more intresting thing. Why > don't add useful things, if programmers want to see it? Oh, I see, > this is dangerous because will lead to real projects and paid job ;) No, because a small Forth is better than a big one, and the number of potentially useful hooks is very large. In order to justify its inclusion in a standard, a feature has to be needed by many people. C++ and Java are over there. --> Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-05-21 10:23 +0000 |
| Message-ID | <slrnnk0hb5.pb.albert@cherry.spenarnc.xs4all.nl> |
| In reply to | #47398 |
On 2016-05-21, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >>> > Can't you see in this case you simple use Forth interpreter once to >>> > run another interpreter? >>> >>> Yes. >> >> On this way you can simple run MS Visual Studio from your Forth. > > Probably, but what for? > >>> It's your Forth, so do what you like. The only interesting question >>> for me is what should be standard. >> >> I know this is my Forth. Interesing question from me - what is >> standard goals? With no goal declared this is no chance to decide >> use it ir not. I don't know where ANS-Forth going and can't be sure >> it is going in right direction. > > There are two goals: common libraries and a common language. Without > some common understaning about what Forth is, we can't even talk about > Forth programs. > >>> No. I think you're misunderstanding what Chuck wrote. If you >>> actually *use* a hook, then the probability of it being used is 1, not >>> 0. Chuck was talking about *speculative* hooks, and there is a huge >>> difference. >> >> But I point you to real used things, not to hooks for future use by >> someone. LITERAL is required. EMIT is very useful. DISPATCH-NUMBER >> was used by me yesterday to convert several files with numbers in >> text format. Reaction of ANS committee is more intresting thing. Why >> don't add useful things, if programmers want to see it? Oh, I see, >> this is dangerous because will lead to real projects and paid job ;) > > No, because a small Forth is better than a big one, and the number of > potentially useful hooks is very large. In order to justify its > inclusion in a standard, a feature has to be needed by many people. > C++ and Java are over there. --> And if you really fear that about every word may be in need of revectoring use an indirect threaded Forth. E.g. if NAME is the word CREATE get's it name from, you can revector it for one invocation to a word that ... restores the former behaviour. Revectoring is a matter of filling in the data field addres. Remember for docol the executed code is data. The way is to prepend the creating word ( : CONSTANT VARIABLE VALUE create-does-constructs ) by POSTFIX: The following is working code, but you should read only the comment. 7 \ Have the original behaviour of DEA restored. 8 : RESTORED DUP >PHA SWAP >DFA ! ; 9 \ Do nothing for one call of ``NAME'' 10 : NAME-NEW 'NAME RESTORED ; 11 \ Make the following defining word postfix for one execution. 12 \ The name must be a string constant on the stack 13 \ Use only while compiling, or you crash the system 14 : POSTFIX ( ?COMP ) 'NAME-NEW >DFA @ 'NAME >DFA ! ; Like so. "2DROP" POSTFIX : DROP DROP ; It is unwise to try to think up these things before hand. > Andrew. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Ilya Tarasov <ilya74.tarasov@gmail.com> |
|---|---|
| Date | 2016-05-22 13:37 -0700 |
| Message-ID | <bc59b915-9394-4467-96d1-c10ada767d53@googlegroups.com> |
| In reply to | #47398 |
> >> > Can't you see in this case you simple use Forth interpreter once to > >> > run another interpreter? > >> > >> Yes. > > > > On this way you can simple run MS Visual Studio from your Forth. > > Probably, but what for? If you have INTERPRET, but use it only once to run your INTERPRET2, you will switch to another version of Forth right after launching. So why do you need to standartize INTERPRET? On this way, you can run INTERPRET2, INTERPRET3, or even MS Visual Studio. All of these programs are not original INTERPRET, and rewrited INTERPRET2 is not covered by standars as well as MSVS. > There are two goals: common libraries and a common language. Without > some common understaning about what Forth is, we can't even talk about > Forth programs. Look at my answer to Elizabeth Rather. > No, because a small Forth is better than a big one, and the number of > potentially useful hooks is very large. In order to justify its > inclusion in a standard, a feature has to be needed by many people. > C++ and Java are over there. --> So committee should explain how this features may be added. Otherwise it is chaotic and depended on committee members particular decisions. Indeed this is a real question how to add hooks to make extensions easy-to-add and still not huge. Right now I see only restrictions and remarks about 'non-standard solutions'.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-23 04:38 -0500 |
| Message-ID | <YqSdnZ3WhcUzUt_KnZ2dnUU7-eXNnZ2d@supernews.com> |
| In reply to | #47424 |
Ilya Tarasov <ilya74.tarasov@gmail.com> wrote: >> >> > Can't you see in this case you simple use Forth interpreter once to >> >> > run another interpreter? >> >> >> >> Yes. >> > >> > On this way you can simple run MS Visual Studio from your Forth. >> >> Probably, but what for? > > If you have INTERPRET, but use it only once to run your INTERPRET2, > you will switch to another version of Forth right after > launching. So why do you need to standartize INTERPRET? On this way, > you can run INTERPRET2, INTERPRET3, or even MS Visual Studio. All of > these programs are not original INTERPRET, and rewrited INTERPRET2 > is not covered by standars as well as MSVS. I was going to reply to this, but I don't really understand what it means. >> No, because a small Forth is better than a big one, and the number of >> potentially useful hooks is very large. In order to justify its >> inclusion in a standard, a feature has to be needed by many people. >> C++ and Java are over there. --> > > So committee should explain how this features may be added. > Otherwise it is chaotic and depended on committee members particular > decisions. Of course it depends on committee members' decisions, but I would certainly dispute "chaotic". In the end, programming language design is all about matters of taste and judgement, and this is IMO especially true of languages like Forth. In particular, vendors and industrial users of Forth come to meetings with experience of features which have been tested and found to be useful in multiple real-world applications. They're neither playing games nor advocating cute features for their own sake. I am aware of no better way of standardizing anything. > Indeed this is a real question how to add hooks to make extensions > easy-to-add and still not huge. Right now I see only restrictions > and remarks about 'non-standard solutions'. Forth is all about extending a simple language: that's what it's for. There's only one way to get new language features in: propose something, persuade users that it's so useful they need it, wait for them to test in in real applications, rinse and repeat. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web