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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-05-20 22:11 -1000 |
| Message-ID | <fradnQRyd__Xhd3KnZ2dnUU7-enNnZ2d@supernews.com> |
| In reply to | #47397 |
On 5/20/16 9:52 PM, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: ... >> Well, the ANS cross-compiler extension proposal linked earlier seems >> like it has been useful in practice. > > Shrug. That proposal was incomplete and unsuccessful IIRC. It has been technically very successful, with a large number of major current applications in the field. The drafts are outdated now, and need work, but a cross-compiler standard could be the basis of major market openings for Forth. I think the major reason it hasn't progressed is that the major users (FORTH, Inc. and MPE) are so busy using these techniques in significant projects they haven't had time to refine the proposal. 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-21 03:13 -0500 |
| Message-ID | <-KadncKR1OU0hd3KnZ2dnUU7-TGdnZ2d@supernews.com> |
| In reply to | #47397 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Paul Rubin <no.email@nospam.invalid> wrote: >> >> Well, the ANS cross-compiler extension proposal linked earlier seems >> like it has been useful in practice. > > Shrug. That proposal was incomplete and unsuccessful IIRC. I just read Elizabeth's reply, and it seems like this proposal has turned out to be useful; mea culpa. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-21 15:43 -0700 |
| Message-ID | <74febe27-73eb-4f7b-b0a9-5c924917e12b@googlegroups.com> |
| In reply to | #47397 |
On Saturday, May 21, 2016 at 12:52:06 AM UTC-7, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > You want the host's version of DUP to be different than the target's > > version. Maybe there's a way to do this with word lists, but it would > > have been a lot cleaner to supply a generalized dictionary interface. > > Eh? This is exactly the sort of thing for which wordlists have been > used for more than thirty years. They're exactly what is needed for > cross-compiling. I did this in MFX with the Forth-83 vocabularies using CONTEXT and CURRENT. Cross-compilation is not "exactly the sort of thing for which wordlists have been used for more than thirty years." Ray Duncan described the ONLY ALSO scheme as being "brain-damaged" in 1993, and he was right. When I tried to use wordlists in my ANS-Forth cross-compiler in 2010 I found it unusable. I fixed all of these problems, getting ANS-Forth up to the level of Forth-83. These fixes are now in the latest version of the novice-package (see the "some word-list stuff" section) --- I can email this to anybody who wants it. Andrew Haley doesn't know how to write a cross-compiler --- he is just brown-nosing Elizabeth Rather when he says that ANS-Forth is "exactly" correct --- he has no personal experience with this stuff. Also, saying that ANS-Forth is 30 years old is an exaggeration. That ONLY ALSO scheme does predate ANS-Forth (I remember it being discussed in "Forth Dimensions"), but I'm not aware of anybody using it for anything --- it really is ill-conceived --- a screw-ball idea that has never been tried out in practice.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-22 22:22 -0700 |
| Message-ID | <87zirhgxh6.fsf@jester.gateway.pace.com> |
| In reply to | #47397 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> The more featureful text interpreters can also get somewhat >> complicated: think of gforth locals, for example. > Sure, but it's quite possible that a target's way of handling locals > will be different from that of the host. I can't see much advantage > to sharing just the text interpreter part of that. The idea is the cross-compiler should be able to compile itself. It should also be expected to be written in itself; i.e., if it supports gforth locals it should be allowed to use them in its own implementation. So the secondary text interpreter has to deal with them somehow. I have to admit that the idea of a second text interpreter didn't occur to me when I thought about this problem a year or so ago, after reading Jay Melvin's article about the CMForth metacompiler. I liked the idea of a compiler that could completely compile itself starting from a minimal shim. eForth does something like it, but iirc, it used some some non-ANS machinery, that might or might not have been essential. > Eh? This is exactly the sort of thing for which wordlists have been > used for more than thirty years. They're exactly what is needed for > cross-compiling. The ANS wordlist extension appears to be a complete mess. It was designed to implement things like CODE, but a cross compiler seems much more painful, and unnecessarily so. Anton posted some ugly code to implement gforth's EXECUTE-PARSING with word lists, and that might help implement a cleaner dictionary. Again, I confess not having realized that was even possible, before examining Anton's implementation.
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-05-23 08:30 +0200 |
| Message-ID | <86lh31i8v7.fsf@molnjunk.nocrew.org> |
| In reply to | #47432 |
Paul Rubin <no.email@nospam.invalid> writes: > The ANS wordlist extension appears to be a complete mess. It was > designed to implement things like CODE, but a cross compiler seems > much more painful, and unnecessarily so. It's not that painful. Why do you this so? If you do it the usual way (which is explained in several Forth Dimensions articles), it's actually quite easy.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-22 23:39 -0700 |
| Message-ID | <bb98c7e8-8cae-44dc-98f2-30cdae2ccd8f@googlegroups.com> |
| In reply to | #47433 |
On Sunday, May 22, 2016 at 11:30:54 PM UTC-7, Lars Brinkhoff wrote: > Paul Rubin <no.email@nospam.invalid> writes: > > The ANS wordlist extension appears to be a complete mess. It was > > designed to implement things like CODE, but a cross compiler seems > > much more painful, and unnecessarily so. > > It's not that painful. Why do you this so? If you do it the usual way > (which is explained in several Forth Dimensions articles), it's actually > quite easy. There are no Forth Dimensions articles that explain cross-compilers --- cross-compilers are not "quite easy" --- you're making this stuff up! I remember Forth Dimensions articles that described the ONLY ALSO scheme. I don't recall that the offered any suggestion to what it could be used for --- I'm not aware of there being any use for the ONLY ALSO scheme.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-22 23:36 -0700 |
| Message-ID | <8a015164-3060-4267-bb71-55f9671fa1a2@googlegroups.com> |
| In reply to | #47432 |
On Sunday, May 22, 2016 at 10:22:18 PM UTC-7, Paul Rubin wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > > Eh? This is exactly the sort of thing for which wordlists have been > > used for more than thirty years. They're exactly what is needed for > > cross-compiling. > > The ANS wordlist extension appears to be a complete mess. It was > designed to implement things like CODE, but a cross compiler seems much > more painful, and unnecessarily so. Anton posted some ugly code to > implement gforth's EXECUTE-PARSING with word lists, and that might help > implement a cleaner dictionary. Again, I confess not having realized > that was even possible, before examining Anton's implementation. Actually, the original vocabulary scheme with CONTEXT and CURRENT (as standardized in Forth-83, and afaik also the same in Forth-79) was designed for assemblers. This was pretty simple. A code word would change CONTEXT to ASSEMBLER so it could use the assembler, but CURRENT continued to be whatever vocabulary the programmer was putting the word in (usually FORTH). This allowed the assembler to have words such as OR and AND etc. that are also in Forth. The vocabulary scheme was also used when working with the line-editor. The user could use editor words such as I that are also in Forth. All in all, pretty simple, and it worked quite well for these kinds of uses. My MFX used the Forth-83 vocabulary scheme with CONTEXT and CURRENT and it worked fine. I did have to resort to carnal knowledge of UR/Forth for a few things. I needed to be able to take an xt and determine its attributes (what vocabulary it was defined in, immediate or non-immediate, smudge flag set or not set, smudge-ready flag set or not set), and I needed to change these attributes as needed. This is actually trivial to implement, and it is essential to a cross-compiler. The fact that ANS-Forth didn't provide such essential features, and Forth-200x continues to refuse to do so, implies that the ANS-Forth and Forth-200x committees are purposely crippling the Standard to prevent the common programmers from writing cross-compilers in competition with Forth Inc. and MPE (they presumably have these features for use in their own cross-compilers which are closed-source and are not ANS-Forth). As for the ONLY ALSO scheme that was put in ANS-Forth, this is a screwball system that was not thought out very well. My novice-package fixes this though! I fixed this while maintaining ANS-Forth compatibility. This was two years ago. I can email you the new novice-package that has this fix --- I think that you will be amazed at how much better it works than the ONLY ALSO scheme.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-23 04:24 -0500 |
| Message-ID | <F4-dnYjVfL3WUd_KnZ2dnUU7-THNnZ2d@supernews.com> |
| In reply to | #47432 |
Paul Rubin <no.email@nospam.invalid> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> The more featureful text interpreters can also get somewhat >>> complicated: think of gforth locals, for example. >> Sure, but it's quite possible that a target's way of handling locals >> will be different from that of the host. I can't see much advantage >> to sharing just the text interpreter part of that. > > The idea is the cross-compiler should be able to compile itself. It > should also be expected to be written in itself; i.e., if it > supports gforth locals it should be allowed to use them in its own > implementation. So the secondary text interpreter has to deal with > them somehow. Well, than's *an* idea but I'm not convinced that it's the idea. Sure, the host system has to be created somehow, and that's preferably with a cross-compiler. But real cross-compilers cross compile, by definition, and that means you have a different target and a different implementation of the core, different code generators etc. So, you can either have a cross compiler that enforces very similar implementations of (e.g.) local variables on the host and target or just accept that each has its own. When cross compiling some things are going to be tricky. CREATE DOES> is interesting. CREATE DOES> DOES> is even more interesting. So you might have to provide hints in the source code to help the cross- compiler. That's OK. > I have to admit that the idea of a second text interpreter didn't > occur to me when I thought about this problem a year or so ago, > after reading Jay Melvin's article about the CMForth metacompiler. > I liked the idea of a compiler that could completely compile itself > starting from a minimal shim. eForth does something like it, but > iirc, it used some some non-ANS machinery, that might or might not > have been essential. That might be a cute idea, but the CMForth metacompiler was a real PITA. It was sufficient to allow CMForth to recompile itself, but not much else. I used polyFORTH for Novix which was far better, not least because it used the genuine Target Compiler (TM). >> Eh? This is exactly the sort of thing for which wordlists have >> been used for more than thirty years. They're exactly what is >> needed for cross-compiling. > > The ANS wordlist extension appears to be a complete mess. It was > designed to implement things like CODE, but a cross compiler seems > much more painful, and unnecessarily so. Anton posted some ugly > code to implement gforth's EXECUTE-PARSING with word lists, and that > might help implement a cleaner dictionary. Again, I confess not > having realized that was even possible, before examining Anton's > implementation. Sure, wordlists themselves are not ideal: they're a rather awkward compromise, and I don't think that anyone really likes ONLY/ALSO . But you've lost me. "Cleaner dictionary?" I guess this must refer to some discussion I missed or have forgotten. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-24 09:14 -0700 |
| Message-ID | <45c427e5-5a6b-4fa2-8b55-a412fff7a995@googlegroups.com> |
| In reply to | #47438 |
On Monday, May 23, 2016 at 2:24:29 AM UTC-7, Andrew Haley wrote: > When cross compiling some things are going to be tricky. CREATE DOES> > is interesting. CREATE DOES> DOES> is even more interesting. So you > might have to provide hints in the source code to help the cross- > compiler. That's OK. In MFX I had <BUILDS DOES> that worked just fine. I didn't require any "hints in the source code to help the cross-compiler." When Andrew Haley makes comments like this, he is essentially admitting that he doesn't know how a cross-compiler works --- he is just speculating --- I don't think he has anything worth saying on the subject. > > > I have to admit that the idea of a second text interpreter didn't > > occur to me when I thought about this problem a year or so ago, > > after reading Jay Melvin's article about the CMForth metacompiler. > > I liked the idea of a compiler that could completely compile itself > > starting from a minimal shim. eForth does something like it, but > > iirc, it used some some non-ANS machinery, that might or might not > > have been essential. > > That might be a cute idea, but the CMForth metacompiler was a real > PITA. It was sufficient to allow CMForth to recompile itself, but not > much else. I used polyFORTH for Novix which was far better, not least > because it used the genuine Target Compiler (TM). > > >> Eh? This is exactly the sort of thing for which wordlists have > >> been used for more than thirty years. They're exactly what is > >> needed for cross-compiling. > > > > The ANS wordlist extension appears to be a complete mess. It was > > designed to implement things like CODE, but a cross compiler seems > > much more painful, and unnecessarily so. Anton posted some ugly > > code to implement gforth's EXECUTE-PARSING with word lists, and that > > might help implement a cleaner dictionary. Again, I confess not > > having realized that was even possible, before examining Anton's > > implementation. > > Sure, wordlists themselves are not ideal: they're a rather awkward > compromise, and I don't think that anyone really likes ONLY/ALSO . > But you've lost me. "Cleaner dictionary?" I guess this must refer to > some discussion I missed or have forgotten. > > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-05-23 10:35 +0100 |
| Message-ID | <nhuilj$fo6$1@dont-email.me> |
| In reply to | #47432 |
On 23/05/2016 06:22, Paul Rubin wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> The more featureful text interpreters can also get somewhat
>>> complicated: think of gforth locals, for example.
>> Sure, but it's quite possible that a target's way of handling locals
>> will be different from that of the host. I can't see much advantage
>> to sharing just the text interpreter part of that.
>
> The idea is the cross-compiler should be able to compile itself. It
> should also be expected to be written in itself; i.e., if it supports
> gforth locals it should be allowed to use them in its own
> implementation. So the secondary text interpreter has to deal with them
> somehow.
>
> I have to admit that the idea of a second text interpreter didn't occur
> to me when I thought about this problem a year or so ago, after reading
> Jay Melvin's article about the CMForth metacompiler. I liked the idea
> of a compiler that could completely compile itself starting from a
> minimal shim. eForth does something like it, but iirc, it used some
> some non-ANS machinery, that might or might not have been essential.
>
>> Eh? This is exactly the sort of thing for which wordlists have been
>> used for more than thirty years. They're exactly what is needed for
>> cross-compiling.
Surely a cross compiler designed to compile itself to run on the same
computer, and not designed to compile to any other target, is the easy
case. If dictionary pointers and offsets are switched, which AIUI is the
case with cmForth's { and }, then, presumably, target code can be
executed by the text interpreter to build itself during compilation. 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.
>
> The ANS wordlist extension appears to be a complete mess.
It doesn't seem that way to me. It seems a fairly basic set of building
blocks. But I would like to see a few more words e.g. a way to name a
wordlist that can be displayed by ORDER.
> It was
> designed to implement things like CODE,but a cross compiler seems much
> more painful, and unnecessarily so. Anton posted some ugly code to
> implement gforth's EXECUTE-PARSING with word lists, and that might help
> implement a cleaner dictionary. Again, I confess not having realized
> that was even possible, before examining Anton's implementation.
>
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.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-23 18:53 -0700 |
| Message-ID | <87r3csgr1v.fsf@jester.gateway.pace.com> |
| In reply to | #47440 |
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. > 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 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.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-05-23 19:43 -1000 |
| Message-ID | <MOmdneUTJo5hdN7KnZ2dnUU7-T3NnZ2d@supernews.com> |
| In reply to | #47454 |
On 5/23/16 3:53 PM, 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. > >> 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. There hasn't, afaik, been suffient standard practice to standardize. Historically, FORTH, Inc. used WORD to move the name to where it would be if a new dictionary entry is to be created, before doing the lookup. If the lookup failed, the name could be created. It's a little more complicated nowadays. > I'd consider that absence to be a deficiency of ANS wordlists. 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. The standardization effort has primarily focused on enabling portable applications and portable programmers, rather than standardizing the actual Forth compiler process. We have thought that the more freedom given to implementors the better the implementations would be come. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-24 00:28 -0700 |
| Message-ID | <87mvnfhq33.fsf@jester.gateway.pace.com> |
| In reply to | #47461 |
"Elizabeth D. Rather" <erather@forth.com> writes: >> 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. > The standardization effort has primarily focused on enabling portable > applications and portable programmers, rather than standardizing the > actual Forth compiler process. We have thought that the more freedom > given to implementors the better the implementations would be come. 1) it seems to me that a fair amount of the standard exists to make sure that a standard self-hosted interpreter is possible. Why else are there words like AHEAD? 2) there's certainly lots of ways to implement lookup tables keyed by strings. The more common ones used in compilers make it something of a pain to implement MARK or FORGET, so the standard already creates some constraints on implementation. But there is still a fair amount of freedom, and most ways I can think of make it easy to expose a function like what you mentioned Forth Inc. called WORD. So if that were standardized, I doubt it be much more of a constraint. 3) regarding "the better the implementations would become": there are many interesting challenges in implementing Forth, and the quality of an implementation rests on mostly how well the programmer meets those challenges. However, implementing word lists isn't really one of them. It's very basic, and it was done in unbelievably primitive ways in historical Forths (this is one of the aspects of Forth that makes it special, and I mean that in a good way). The question is what interface should the word list code present to the application programmer. It looks to me like ANS (maybe based on earlier practice) chose an interface that could have been a lot better. The gforth manual at http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Why-use-word-lists_003f.html describes some of the issues.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-05-23 21:53 -1000 |
| Message-ID | <PMidncGIeaf9ldnKnZ2dnUU7-T3NnZ2d@supernews.com> |
| In reply to | #47465 |
On 5/23/16 9:28 PM, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >>> 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. >> The standardization effort has primarily focused on enabling portable >> applications and portable programmers, rather than standardizing the >> actual Forth compiler process. We have thought that the more freedom >> given to implementors the better the implementations would be come. > > 1) it seems to me that a fair amount of the standard exists to make sure > that a standard self-hosted interpreter is possible. Why else are there > words like AHEAD? More like allowing building blocks for cross compilers, IMO. > 2) there's certainly lots of ways to implement lookup tables keyed by > strings. The more common ones used in compilers make it something of a > pain to implement MARK or FORGET, so the standard already creates some > constraints on implementation. But there is still a fair amount of > freedom, and most ways I can think of make it easy to expose a function > like what you mentioned Forth Inc. called WORD. So if that were > standardized, I doubt it be much more of a constraint. 6.1.2450 WORD was included in Forth94 and Forth2012. > 3) regarding "the better the implementations would become": there are > many interesting challenges in implementing Forth, and the quality of an > implementation rests on mostly how well the programmer meets those > challenges. However, implementing word lists isn't really one of them. > It's very basic, and it was done in unbelievably primitive ways in > historical Forths (this is one of the aspects of Forth that makes it > special, and I mean that in a good way). The question is what interface > should the word list code present to the application programmer. It > looks to me like ANS (maybe based on earlier practice) chose an > interface that could have been a lot better. The gforth manual at > > http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Why-use-word-lists_003f.html > > describes some of the issues. In the first year after Chuck developed "vocabularies" (now called word lists) he used them extensively. Since then, the number of wordlists even in significant applications has decreased. The development of OOP in Forth, at least as far as FORTH, Inc.'s SWOOP is concerned, uses unnamed wordlists extensively, but I haven't heard of serious problems or inhibitions. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-24 01:56 -0700 |
| Message-ID | <87eg8rhm1b.fsf@jester.gateway.pace.com> |
| In reply to | #47467 |
"Elizabeth D. Rather" <erather@forth.com> writes: > 6.1.2450 WORD was included in Forth94 and Forth2012. Oh, nice. > In the first year after Chuck developed "vocabularies" (now called > word lists) he used them extensively. Since then, the number of > wordlists even in significant applications has decreased. I think except for implementations of Forth itself, Forth programs don't tend to be of the type that uses a lot of strings as data. I'm probably more accustomed than most hardcore Forthers to programming in that style. But from that perspective, tables indexed by strings (basically, Forth word lists with a different interface) are very useful. Most languages in significantly wide use these days supply them.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-24 09:03 -0700 |
| Message-ID | <304bd756-77ad-4b78-9838-2e120703ae5a@googlegroups.com> |
| In reply to | #47469 |
On Tuesday, May 24, 2016 at 1:56:18 AM UTC-7, Paul Rubin wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > > 6.1.2450 WORD was included in Forth94 and Forth2012. > > Oh, nice. > > > In the first year after Chuck developed "vocabularies" (now called > > word lists) he used them extensively. Since then, the number of > > wordlists even in significant applications has decreased. > > I think except for implementations of Forth itself, Forth programs don't > tend to be of the type that uses a lot of strings as data. I'm probably > more accustomed than most hardcore Forthers to programming in that > style. But from that perspective, tables indexed by strings (basically, > Forth word lists with a different interface) are very useful. Most > languages in significantly wide use these days supply them. I have ASSOCIATION.4TH in the novice package --- this is an LLRB tree that can use strings as keys --- I've had that for at least 5 years.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-05-24 22:09 +0000 |
| Message-ID | <ni2jf4$jfh$1@dont-email.me> |
| In reply to | #47469 |
Paul Rubin wrote:
> I think except for implementations of Forth itself, Forth programs don't
> tend to be of the type that uses a lot of strings as data. I'm probably
> more accustomed than most hardcore Forthers to programming in that
> style. But from that perspective, tables indexed by strings (basically,
> Forth word lists with a different interface) are very useful. Most
> languages in significantly wide use these days supply them.
I suppose I shouldn't have been astonished that you had to explain
"tables indexed by strings" and their widespread use to Mrs. Rather.
OCaml:
#load "str.cma" ;;
open String ;;
let table = Hashtbl.create 99 ;;
"I think except for implementations of Forth itself, Forth programs don't
tend to be of the type that uses a lot of strings as data. I'm probably
more accustomed than most hardcore Forthers to programming in that
style. But from that perspective, tables indexed by strings (basically,
Forth word lists with a different interface) are very useful. Most
languages in significantly wide use these days supply them."
|> Str.split (Str.regexp "[^a-zA-Z]")
|> List.filter (fun s -> length s > 4)
|> List.iter
(fun s -> Hashtbl.replace table s
(1 + (try Hashtbl.find table s with Not_found -> 0))) ;;
Hashtbl.fold (fun s n list -> (s,n) :: list) table []
|> List.sort (fun (a,b) (c,d) -> compare (uppercase a) (uppercase c))
|> List.iter (fun (s,n) -> Printf.printf "%s %d\n" s n) ;;
accustomed 1
basically 1
different 1
except 1
Forth 3
Forthers 1
hardcore 1
implementations 1
indexed 1
interface 1
itself 1
languages 1
lists 1
perspective 1
probably 1
programming 1
programs 1
significantly 1
strings 2
style 1
supply 1
tables 1
these 1
think 1
useful 1
--
If confirmed, Garland would be the fourth Jewish justice on the nation's
highest court, which is comprised entirely of Jews and Catholics. The three
current Jewish members of the Supreme Court are Ruth Bader Ginsburg, Elana
Kagan, and Stephen Breyer.
www.jta.org/2016/03/16/news-opinion/united-states/obama-to-name-jewish-federal-judge-to-supreme-court
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-05-23 22:59 -0700 |
| Message-ID | <b3deea5c-aa6a-43c7-a696-4311404dfde7@googlegroups.com> |
| In reply to | #47454 |
On Monday, May 23, 2016 at 6:53:22 PM UTC-7, Paul Rubin wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> > 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 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.
I have :NAME in the novice-package that does all of this --- this was another RfD of mine that got killed by the Forth-200x committee.
: :name ( str wid -- ) \ like colon except takes its name as a parameter
get-current >r set-current
<cstr
c" : " +cstr +cstr c" " +cstr
cstr> count evaluate
r> set-current ;
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-05-24 04:32 -0500 |
| Message-ID | <AJ-dnS8VJoMGgtnKnZ2dnUU78KednZ2d@supernews.com> |
| In reply to | #47454 |
Paul Rubin <no.email@nospam.invalid> wrote: > 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. That all sounds rather indirect and complex. >> 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 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). That's not really useful because there are many different kinds of words: VARIABLEs, colon definitions, CREATED words, etc. > 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. That one isn't a problem: when cross-compiling you'd arrange for some command which sets the search order as appropriate. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-05-24 12:46 -0700 |
| Message-ID | <8760u3grxi.fsf@jester.gateway.pace.com> |
| In reply to | #47470 |
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. >> 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 the other words the usual way, defining VARIABLE using CREATE etc. I think eForth works like that. >> 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. That's probably true. But an equally simple (or maybe simpler) design could have been contortion-free.
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.forth
csiph-web