Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55085 > unrolled thread
| Started by | jim <njbetts@gmail.com> |
|---|---|
| First post | 2017-02-24 15:05 -0800 |
| Last post | 2017-02-27 01:21 -0500 |
| Articles | 20 on this page of 189 — 21 participants |
Back to article view | Back to comp.lang.forth
The Wikipedia article on Forth jim <njbetts@gmail.com> - 2017-02-24 15:05 -0800
The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-02-24 15:14 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-24 23:38 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-25 04:51 -0600
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-25 13:00 +0100
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-26 14:29 +1100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 09:30 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 02:44 -0800
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-02-26 03:12 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 03:25 -0800
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-26 14:00 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 14:32 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 22:58 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 15:29 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-26 21:57 -0500
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 19:17 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-26 22:21 -0500
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-26 15:41 -0800
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-26 14:46 -1000
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-26 17:08 -0800
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-26 15:18 -1000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 14:20 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-27 17:47 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 15:16 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-27 19:04 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 21:52 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 01:12 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 03:33 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 19:23 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-01 08:04 -0800
Re: The Wikipedia article on Forth Cecil Bayona <cbayona@cbayona.com> - 2017-02-27 18:54 -0600
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 03:17 -0800
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-28 03:50 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 05:28 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-28 13:59 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-03-01 08:25 -0800
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-27 23:00 -0800
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-28 11:51 +0100
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-02-28 05:19 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 19:34 -0500
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-28 03:42 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-10 10:16 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-09 18:21 -0500
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-09 23:44 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-09 19:55 -0500
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-03-10 11:24 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-10 13:38 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-11 12:08 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-09 16:34 -1000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-09 22:43 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-11 15:23 +1100
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-10 21:17 +1100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-11 12:06 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 05:32 -0500
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-12 11:17 +0000
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 13:18 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-12 14:59 +0000
Re: The Wikipedia article on Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-03-12 15:00 -0400
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-13 10:43 +1100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-13 07:57 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-13 10:26 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-10 03:27 -0600
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-10 08:47 -1000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-11 01:57 -0600
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 10:00 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 18:32 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 11:52 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 20:23 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 11:21 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 19:41 +0000
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 11:55 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-26 20:14 +0000
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-02-26 12:37 -0800
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-26 14:26 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-27 14:10 +1100
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 19:43 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-27 04:13 -0600
Re: The Wikipedia article on Forth Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-02-27 14:31 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-02-28 03:53 -0600
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-27 13:15 +1100
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-02-27 02:22 -0800
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-27 15:52 -1000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-28 14:44 +1100
Re: The Wikipedia article on Forth Paul Rubin <no.email@nospam.invalid> - 2017-02-27 22:55 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-04 21:38 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-04 06:11 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:21 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-04 13:27 -0500
Re: The Wikipedia article on Forth JUERGEN <epldfpga@aol.com> - 2017-03-05 08:50 -0800
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 15:12 +0000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-05 18:25 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-05 02:38 -0500
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-07 18:20 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 02:45 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-07 08:54 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 04:42 -0500
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-07 04:06 -0600
Re: The Wikipedia article on Forth Roelf Toxopeus <rt4all@nothishetnet.nl> - 2017-03-07 13:02 +0100
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 18:43 +1100
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-07 22:04 -1000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 19:49 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-08 19:02 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 10:06 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-08 03:35 -0500
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-08 13:41 +0000
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-08 15:29 +0100
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-08 15:10 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-07 08:31 +0000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:03 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-11 22:56 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 05:36 -0500
Re: The Wikipedia article on Forth stephen@mpeforth.com (Stephen Pelc) - 2017-03-12 15:14 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-12 19:46 -0700
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:09 +0000
Re: The Wikipedia article on Forth alex@rivadpm.com - 2017-03-05 15:28 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-05 22:05 +0000
Re: The Wikipedia article on Forth julian.fondren@endurance.com - 2017-03-04 07:23 -0800
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:11 +0000
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-03-04 07:25 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-05 19:10 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-05 04:27 -0500
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-05 18:24 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-07 18:16 +1100
Re: The Wikipedia article on Forth stephen@mpeforth.com (Stephen Pelc) - 2017-03-07 11:35 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-07 17:13 -1000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 19:10 +1100
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-08 03:38 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 10:18 +0000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:41 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-11 16:50 -1000
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 09:56 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-12 14:31 -1000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-15 23:54 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 19:00 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 21:27 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 21:39 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-15 22:13 -0700
Re: The Wikipedia article on Forth stephen@mpeforth.com (Stephen Pelc) - 2017-03-16 10:20 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-12 19:42 -0700
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-12 19:39 -0700
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 05:48 -0500
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-06 01:26 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-06 05:33 -0500
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-06 04:33 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-06 17:16 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-06 12:28 -0600
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-06 11:10 -0800
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-06 11:12 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-06 15:22 -0500
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-03-06 12:28 -0800
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-07 02:51 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-07 13:13 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 14:50 -0500
Re: The Wikipedia article on Forth Julian Fondren <julian.fondren@gmail.com> - 2017-03-07 12:06 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-03-07 16:00 -0500
Re: The Wikipedia article on Forth julian.fondren@endurance.com - 2017-03-07 13:18 -0800
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 00:16 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 03:04 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 09:52 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 05:09 -0600
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 14:05 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 12:05 -0600
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-08 03:00 -0600
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 22:53 +0000
Re: The Wikipedia article on Forth Bernd Paysan <bernd@net2o.de> - 2017-03-11 23:19 +0000
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-03-11 17:01 -1000
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 10:12 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 07:02 -0500
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 12:43 +0000
Re: The Wikipedia article on Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-12 12:28 -0500
Re: The Wikipedia article on Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-12 16:29 +0100
Re: The Wikipedia article on Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-12 16:16 +0000
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-03-12 21:42 +0000
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-08 19:13 +1100
Re: The Wikipedia article on Forth Mark Wills <markwills1970@gmail.com> - 2017-03-08 01:33 -0800
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-03-10 10:37 +1100
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-03-04 18:35 -0800
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-27 23:12 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-27 13:13 +0000
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-27 23:28 -0800
Re: The Wikipedia article on Forth Alex <alex@rivadpm.com> - 2017-02-28 07:49 +0000
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-28 03:32 -0500
Re: The Wikipedia article on Forth "HAA" <someone@microsoft.com> - 2017-02-25 11:55 +1100
Re: The Wikipedia article on Forth "Elizabeth D. Rather" <erather@forth.com> - 2017-02-24 22:14 -1000
Re: The Wikipedia article on Forth Roelf Toxopeus <rt4all@nothishetnet.nl> - 2017-02-26 15:15 +0100
Re: The Wikipedia article on Forth hughaguilar96@gmail.com - 2017-02-26 20:02 -0800
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-26 23:08 -0500
Re: The Wikipedia article on Forth Cecil Bayona <cbayona@cbayona.com> - 2017-02-26 23:27 -0600
Re: The Wikipedia article on Forth rickman <gnuarm@gmail.com> - 2017-02-27 01:21 -0500
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-12 05:48 -0500 |
| Message-ID | <tdmdnYhekMDxuljFnZ2dnUU7-XHNnZ2d@supernews.com> |
| In reply to | #55641 |
Bernd Paysan <bernd@net2o.de> wrote:
>
> But Leon says something like "The idea is good, but our customers have
> code with <property x>, and won't change their code, so the proposal
> needs to be compatible with that", then he loses credibility if Forth
> Inc. actually doesn't implement Forth-2012.
I don't think it does.
Locals aren't very useful [*] so it's important that a locals syntax
doesn't impinge on other usages of { . Therefore, even if a vendor
doesn't implement all of Forth-20xx with its bells, whistles, and
curlicues, it's not unreasonable to say that portability would be
harmed if a word like { were to be defined by the standard and
therefore { could no longer be used for a comment.
Andrew.
[*] I don't entirely agree with this point of view, and can see some
valid uses for them. But in some parts of the Forth community,
especially the Forth, Inc, world, they are very little used.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-06 01:26 -0800 |
| Message-ID | <9109bc05-0123-4f3a-a5a0-8af4d316aa09@googlegroups.com> |
| In reply to | #55408 |
Being a supporter of the effort to move towards a standard is plain common sense. The Forth committee needs to expend its future efforts on reducing the number of ambiguities in the standard, steered by the committee chair. However, it seems there's not really a consensus (among the committee) of what the ambiguities actually are, so I don't hold out much hope; which is why I've not got involved in the standards process, despite a number of private requests to do so. I think it would be too frustrating. I'd say the standard is nearly there. It's these last issues that are going to be the hardest to resolve. Newer issues such as quotations etc. while quite nice, are lower in priority than solving these last few disagreements with the standard. I look forward to the day when I can run all but the most menial of Forth programs on a multitude of Forth systems. Ironically, we were much closer to that goal with Forth 83 than ANS, and that's a shame, and - I hope - serves to put things into a rather sobering perspective.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-06 05:33 -0500 |
| Message-ID | <o9jdos$9c7$2@dont-email.me> |
| In reply to | #55446 |
On 3/6/2017 4:26 AM, Mark Wills wrote: > Being a supporter of the effort to move towards a standard is plain > common sense. > > The Forth committee needs to expend its future efforts on reducing > the number of ambiguities in the standard, steered by the committee > chair. However, it seems there's not really a consensus (among the > committee) of what the ambiguities actually are, so I don't hold out > much hope; which is why I've not got involved in the standards > process, despite a number of private requests to do so. I think it > would be too frustrating. What do you see as the "ambiguities"? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-06 04:33 -0600 |
| Message-ID | <BsydnajghICKpiDFnZ2dnUU7-U-dnZ2d@supernews.com> |
| In reply to | #55446 |
Mark Wills <markwills1970@gmail.com> wrote: > Being a supporter of the effort to move towards a standard is plain > common sense. > > The Forth committee needs to expend its future efforts on reducing > the number of ambiguities in the standard, steered by the committee > chair. However, it seems there's not really a consensus (among the > committee) of what the ambiguities actually are, so I don't hold out > much hope; which is why I've not got involved in the standards > process, despite a number of private requests to do so. I think it > would be too frustrating. Are there any known ambiguities left? I know that there is some (actually, a lot) of implementation-defined behaviour, but that is very different. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-06 17:16 +0000 |
| Message-ID | <2017Mar6.181643@mips.complang.tuwien.ac.at> |
| In reply to | #55450 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Mark Wills <markwills1970@gmail.com> wrote:
>
>> Being a supporter of the effort to move towards a standard is plain
>> common sense.
>>
>> The Forth committee needs to expend its future efforts on reducing
>> the number of ambiguities in the standard, steered by the committee
>> chair. However, it seems there's not really a consensus (among the
>> committee) of what the ambiguities actually are, so I don't hold out
>> much hope; which is why I've not got involved in the standards
>> process, despite a number of private requests to do so. I think it
>> would be too frustrating.
>
>Are there any known ambiguities left?
There are a lot of ambiguous conditions left. We are working on
eliminating some on them, but others are going to stay.
>I know that there is some
>(actually, a lot) of implementation-defined behaviour, but that is
>very different.
Well, the typical description for implementation-defined behaviour in
the standard document is "ambiguous condition", so I would not be
surprised if that's what he means with "ambiguity".
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-06 12:28 -0600 |
| Message-ID | <gfedneNIkMrFNyDFnZ2dnUU7-SGdnZ2d@supernews.com> |
| In reply to | #55469 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Mark Wills <markwills1970@gmail.com> wrote: >> >>> Being a supporter of the effort to move towards a standard is plain >>> common sense. >>> >>> The Forth committee needs to expend its future efforts on reducing >>> the number of ambiguities in the standard, steered by the committee >>> chair. However, it seems there's not really a consensus (among the >>> committee) of what the ambiguities actually are, so I don't hold out >>> much hope; which is why I've not got involved in the standards >>> process, despite a number of private requests to do so. I think it >>> would be too frustrating. >> >>Are there any known ambiguities left? > > There are a lot of ambiguous conditions left. We are working on > eliminating some on them, but others are going to stay. > >>I know that there is some (actually, a lot) of >>implementation-defined behaviour, but that is very different. > > Well, the typical description for implementation-defined behaviour > in the standard document is "ambiguous condition", so I would not be > surprised if that's what he means with "ambiguity". Perhaps that is what he means, but they aren't ambiguities in the standard. As I said last time this came up, I'd like to see a list of what ambiguous conditions ought to be changed, and why. As far as I know none of us want Forth to turn into a kind of Write Once Run Anywhere virtual machine with identical semantics on all hardware. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-06 11:10 -0800 |
| Message-ID | <38334a69-e147-466b-83ab-aab7411f8fae@googlegroups.com> |
| In reply to | #55471 |
"1. Introduction1.1 PurposeThe purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language."
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2017-03-06 11:12 -0800 |
| Message-ID | <1db2d31b-fddc-402a-9fa8-10dda2c40709@googlegroups.com> |
| In reply to | #55471 |
"1. Introduction 1.1 PurposeThe purpose of this Standard is to promote the portability of Forth programs for use on a wide variety of computing systems, to facilitate the communication of programs, programming techniques, and ideas among Forth programmers, and to serve as a basis for the future evolution of the Forth language."
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-06 15:22 -0500 |
| Message-ID | <o9kg8b$aob$2@dont-email.me> |
| In reply to | #55471 |
On 3/6/2017 1:28 PM, Andrew Haley wrote: > > As I said last time this came up, I'd like to see a list of what > ambiguous conditions ought to be changed, and why. As far as I know > none of us want Forth to turn into a kind of Write Once Run Anywhere > virtual machine with identical semantics on all hardware. Why? Would that be so horrible? Are you saying the limitations this would require would be unacceptable? Can you give examples? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-06 12:28 -0800 |
| Message-ID | <83e06081-c8f3-4aaf-a819-f64efef6456f@googlegroups.com> |
| In reply to | #55476 |
On Monday, March 6, 2017 at 2:22:11 PM UTC-6, rickman wrote: > On 3/6/2017 1:28 PM, Andrew Haley wrote: > > > > As I said last time this came up, I'd like to see a list of what > > ambiguous conditions ought to be changed, and why. As far as I know > > none of us want Forth to turn into a kind of Write Once Run Anywhere > > virtual machine with identical semantics on all hardware. > > Why? Would that be so horrible? Are you saying the limitations this > would require would be unacceptable? Can you give examples? > Example 1. bit-widths would be constant, regardless of the machine.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-07 02:51 -0600 |
| Message-ID | <EJadnVpSgbs-6SPFnZ2dnUU7-XWdnZ2d@supernews.com> |
| In reply to | #55476 |
rickman <gnuarm@gmail.com> wrote: > On 3/6/2017 1:28 PM, Andrew Haley wrote: >> >> As I said last time this came up, I'd like to see a list of what >> ambiguous conditions ought to be changed, and why. As far as I know >> none of us want Forth to turn into a kind of Write Once Run Anywhere >> virtual machine with identical semantics on all hardware. > > Why? Would that be so horrible? Are you saying the limitations this > would require would be unacceptable? Can you give examples? Forth, by design, exposes programs to of low-level machine details, partly for efficiency's sake. You wouldn't want to impose, say, 8-bit bytes on machines which didn't support them in hardware. This stuff isn't easy: we did finally standardize 1 CHARS = 1 at the last meeting, but it was controversial. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-07 13:13 +0000 |
| Message-ID | <2017Mar7.141301@mips.complang.tuwien.ac.at> |
| In reply to | #55486 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>rickman <gnuarm@gmail.com> wrote:
>> On 3/6/2017 1:28 PM, Andrew Haley wrote:
>>>
>>> As I said last time this came up, I'd like to see a list of what
>>> ambiguous conditions ought to be changed, and why. As far as I know
>>> none of us want Forth to turn into a kind of Write Once Run Anywhere
>>> virtual machine with identical semantics on all hardware.
>>
>> Why? Would that be so horrible? Are you saying the limitations this
>> would require would be unacceptable? Can you give examples?
What happens if you do
32767 1+ .
1) Will it print 32768?
2) Will it print -32768?
3) Will it produce an exception during "1+"?
Forth-94 and Forth-2012 allows systems to do either, Forth-200x
(post-2012) does not allow option 3), and an identical-semantics VM
would have to specify exactly one of these options, on all kinds of
hardware (16-bit, 32-bit and 64-bit CPUs).
>Forth, by design, exposes programs to of low-level machine details,
>partly for efficiency's sake. You wouldn't want to impose, say, 8-bit
>bytes on machines which didn't support them in hardware. This stuff
>isn't easy: we did finally standardize 1 CHARS = 1 at the last
>meeting, but it was controversial.
And 1 CHARS=1 works perfectly fine on word-addressed hardware. The
resistance to 1 CHARS=1 came from an implementor who implemented Forth
on top of the JVM, and made some unusual decisions; in particular, he
decided to have 16-bit chars together with 8-bit address units (I see
no technical reason to have 8-bit address units in that setting).
- 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-07 14:50 -0500 |
| Message-ID | <o9n2ou$qgi$1@dont-email.me> |
| In reply to | #55496 |
On 3/7/2017 8:13 AM, Anton Ertl wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >> rickman <gnuarm@gmail.com> wrote: >>> On 3/6/2017 1:28 PM, Andrew Haley wrote: >>>> >>>> As I said last time this came up, I'd like to see a list of what >>>> ambiguous conditions ought to be changed, and why. As far as I know >>>> none of us want Forth to turn into a kind of Write Once Run Anywhere >>>> virtual machine with identical semantics on all hardware. >>> >>> Why? Would that be so horrible? Are you saying the limitations this >>> would require would be unacceptable? Can you give examples? > > What happens if you do > > 32767 1+ . > > 1) Will it print 32768? > 2) Will it print -32768? > 3) Will it produce an exception during "1+"? > > Forth-94 and Forth-2012 allows systems to do either, Forth-200x > (post-2012) does not allow option 3), and an identical-semantics VM > would have to specify exactly one of these options, on all kinds of > hardware (16-bit, 32-bit and 64-bit CPUs). > >> Forth, by design, exposes programs to of low-level machine details, >> partly for efficiency's sake. You wouldn't want to impose, say, 8-bit >> bytes on machines which didn't support them in hardware. This stuff >> isn't easy: we did finally standardize 1 CHARS = 1 at the last >> meeting, but it was controversial. > > And 1 CHARS=1 works perfectly fine on word-addressed hardware. The > resistance to 1 CHARS=1 came from an implementor who implemented Forth > on top of the JVM, and made some unusual decisions; in particular, he > decided to have 16-bit chars together with 8-bit address units (I see > no technical reason to have 8-bit address units in that setting). Maybe because that was the way the addressing worked on that machine? How would you make Forth addresses count words while the CPU counted bytes without adding needless instructions to convert in every memory access instruction? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-07 12:06 -0800 |
| Message-ID | <5c548c9f-bbd8-455b-841c-4e89076ab48b@googlegroups.com> |
| In reply to | #55513 |
On Tuesday, March 7, 2017 at 1:50:31 PM UTC-6, rickman wrote: > On 3/7/2017 8:13 AM, Anton Ertl wrote: > > > > And 1 CHARS=1 works perfectly fine on word-addressed hardware. The > > resistance to 1 CHARS=1 came from an implementor who implemented Forth > > on top of the JVM, and made some unusual decisions; in particular, he > > decided to have 16-bit chars together with 8-bit address units (I see > > no technical reason to have 8-bit address units in that setting). > > Maybe because that was the way the addressing worked on that machine? By 'the JVM', Anton means the Java Virtual Machine. This is a VM invented for the Java programming language, which has constant bit-widths and such that don't vary by implementing or host architecture. You can learn more about it at https://infogalactic.com/info/Java_(programming_language) It's actually a fairly popular language! You'll be surprised by how many know of it. And the JVM is a stack machine! By the story, the author of that Forth chose to use a char[] (16-bit) instead of a byte[] (8-bit) array for Forth's memory. I've made that mistake myself, of forgetting that a 'char' was a 16-bit type.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-03-07 16:00 -0500 |
| Message-ID | <o9n6sk$8rl$1@dont-email.me> |
| In reply to | #55514 |
On 3/7/2017 3:06 PM, Julian Fondren wrote: > On Tuesday, March 7, 2017 at 1:50:31 PM UTC-6, rickman wrote: >> On 3/7/2017 8:13 AM, Anton Ertl wrote: >>> >>> And 1 CHARS=1 works perfectly fine on word-addressed hardware. The >>> resistance to 1 CHARS=1 came from an implementor who implemented Forth >>> on top of the JVM, and made some unusual decisions; in particular, he >>> decided to have 16-bit chars together with 8-bit address units (I see >>> no technical reason to have 8-bit address units in that setting). >> >> Maybe because that was the way the addressing worked on that machine? > > By 'the JVM', Anton means the Java Virtual Machine. This is a VM > invented for the Java programming language, which has constant > bit-widths and such that don't vary by implementing or host > architecture. You can learn more about it at > https://infogalactic.com/info/Java_(programming_language) > > It's actually a fairly popular language! You'll be surprised by how > many know of it. And the JVM is a stack machine! > > By the story, the author of that Forth chose to use a char[] (16-bit) > instead of a byte[] (8-bit) array for Forth's memory. I've made that > mistake myself, of forgetting that a 'char' was a 16-bit type. But that doesn't answer the question. Or maybe I don't understand what you are saying. Does the JVM address bytes or not? Or is Forth memory space "emulated" with arrays? -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | julian.fondren@endurance.com |
|---|---|
| Date | 2017-03-07 13:18 -0800 |
| Message-ID | <a684caa2-f13d-4ec9-b6c9-f060641400cc@googlegroups.com> |
| In reply to | #55515 |
On Tuesday, March 7, 2017 at 3:00:46 PM UTC-6, rickman wrote: > > But that doesn't answer the question. Or maybe I don't understand what > you are saying. Does the JVM address bytes or not? Or is Forth memory > space "emulated" with arrays? > Ah. Conventionally, it'd have to be emulated, but there's stuff like: https://highlyscalable.wordpress.com/2012/02/02/direct-memory-access-in-java/ that may expose you to the underlying architecture's ideas.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-08 00:16 +0000 |
| Message-ID | <2017Mar8.011636@mips.complang.tuwien.ac.at> |
| In reply to | #55515 |
rickman <gnuarm@gmail.com> writes:
>On 3/7/2017 3:06 PM, Julian Fondren wrote:
>> On Tuesday, March 7, 2017 at 1:50:31 PM UTC-6, rickman wrote:
>>> On 3/7/2017 8:13 AM, Anton Ertl wrote:
>>>>
>>>> And 1 CHARS=1 works perfectly fine on word-addressed hardware. The
>>>> resistance to 1 CHARS=1 came from an implementor who implemented Forth
>>>> on top of the JVM, and made some unusual decisions; in particular, he
>>>> decided to have 16-bit chars together with 8-bit address units (I see
>>>> no technical reason to have 8-bit address units in that setting).
...
>Does the JVM address bytes or not? Or is Forth memory
>space "emulated" with arrays?
Yes, AFAIK the Forth memory in that system is an array of one of the
built-in types of the JVM. The JVM has a pretty abstract memory model
and it does not address bytes in the way that assembly language or
Forth does. You can have an array of bytes in the JVM, but you cannot
access it as an array of chars, array of ints, or array of longs.
Instead, if you want to use it as Forth memory, you have to construct,
say, ints by reading each byte separately, and then combining them
with e.g., shift and or.
That's why I think that a word-addressed model is more appropriate for
a JVM-based implementation: make the memory an array of ints (or
longs, if you want a 64-bit system), and the address unit and Forth
char also take an int. That results in a simpler (and probably
faster) implementation of most Forth operations.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-08 03:04 -0600 |
| Message-ID | <dfydnTD1SMO-VCLFnZ2dnUU7-TOdnZ2d@supernews.com> |
| In reply to | #55517 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > Yes, AFAIK the Forth memory in that system is an array of one of the > built-in types of the JVM. The JVM has a pretty abstract memory > model and it does not address bytes in the way that assembly > language or Forth does. You can have an array of bytes in the JVM, > but you cannot access it as an array of chars, array of ints, or > array of longs. Instead, if you want to use it as Forth memory, you > have to construct, say, ints by reading each byte separately, and > then combining them with e.g., shift and or. That's not good. ByteBuffers are better. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-08 09:52 +0000 |
| Message-ID | <2017Mar8.105211@mips.complang.tuwien.ac.at> |
| In reply to | #55532 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>
>> Yes, AFAIK the Forth memory in that system is an array of one of the
>> built-in types of the JVM. The JVM has a pretty abstract memory
>> model and it does not address bytes in the way that assembly
>> language or Forth does. You can have an array of bytes in the JVM,
>> but you cannot access it as an array of chars, array of ints, or
>> array of longs. Instead, if you want to use it as Forth memory, you
>> have to construct, say, ints by reading each byte separately, and
>> then combining them with e.g., shift and or.
>
>That's not good. ByteBuffers are better.
Did not know about them. They certainly look interesting, especially
because they have methods for accessing the memory as chars, ints,
longs, etc. But I think that an int[] performs better on Intel and
ARM than a ByteBuffer with default order() (BIG_ENDIAN), and even
on SPARC (which is big-endian, but did not support efficient unaligned
accesses last I looked).
OTOH, a ByteBuffer-based approach (even if in the wrong byte order) is
closer to a normal Forth on the same (byte-addressed) hardware than my
word-addressed-emulating approach; and if you want to be close to a
normal Forth, then you implement the char as one byte on that system,
and convert from Forth chars to Java chars only when calling a Java
method that deals with chars.
- 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 | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-03-08 05:09 -0600 |
| Message-ID | <jc2dnXYACfHpeyLFnZ2dnUU7-K3NnZ2d@supernews.com> |
| In reply to | #55534 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > > Did not know about [ByteBuffers]. They certainly look interesting, > especially because they have methods for accessing the memory as > chars, ints, longs, etc. But I think that an int[] performs better > on Intel and ARM than a ByteBuffer with default order() > (BIG_ENDIAN), and even on SPARC (which is big-endian, but did not > support efficient unaligned accesses last I looked). I did a lot of work on ByteBuffers to make them fast. It all depends on how exactly they are used by a Java application, but in many (most, I hope) cases there shouldn't be a significant slowdown over using an int[]. This will be in JDK 9, but anbody working in an area where a ByteBuffer might be useful should anticipate JDK 9. It is true that SPARC and legacy 32-bit ARM won't work as well, but that's their problem, IMO. :-) > OTOH, a ByteBuffer-based approach (even if in the wrong byte order) > is closer to a normal Forth on the same (byte-addressed) hardware > than my word-addressed-emulating approach; and if you want to be > close to a normal Forth, then you implement the char as one byte on > that system, and convert from Forth chars to Java chars only when > calling a Java method that deals with chars. Exactly. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web