Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #53117 > unrolled thread
| Started by | josv@planet.nl |
|---|---|
| First post | 2016-12-06 03:40 -0800 |
| Last post | 2016-12-31 06:42 -0800 |
| Articles | 20 on this page of 149 — 25 participants |
Back to article view | Back to comp.lang.forth
f.) for Gorth josv@planet.nl - 2016-12-06 03:40 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-06 15:48 +0100
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-06 17:59 +0000
Re: f.) for Gorth josv@planet.nl - 2016-12-06 13:17 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-07 11:11 +0000
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-07 06:11 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-07 17:50 +0000
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-07 15:23 +0100
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-08 16:18 +0000
Re: f.) for Gorth josv@planet.nl - 2016-12-07 06:46 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-07 17:41 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-06 10:34 -0800
Re: f.) for Gorth josv@planet.nl - 2016-12-09 12:11 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-23 13:23 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-15 15:42 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-07 13:06 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-06 18:32 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-07 12:41 +0100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-07 19:49 -0800
Re: f.) for Gorth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-08 08:12 +0000
Re: f.) for Gorth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-08 18:53 -0500
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-09 00:01 +0000
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-09 12:17 +0100
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-09 13:01 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-09 11:19 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-08 22:23 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-09 07:11 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 22:40 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-20 23:59 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-21 21:17 -0800
Re: f.) for Gorth The Beez <the.beez.speaks@gmail.com> - 2016-12-13 08:51 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-09 12:47 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-10 11:54 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-09 17:28 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-09 18:20 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-10 14:26 +0000
Re: f.) for Gorth The Beez <the.beez.speaks@gmail.com> - 2016-12-13 09:14 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-13 19:24 +0100
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-14 07:29 -0600
Re: f.) for Gorth Hans Bezemer <the.beez.speaks@gmail.com> - 2016-12-14 18:29 +0100
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-14 10:13 -0800
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 03:45 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-15 10:42 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 05:11 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-15 12:36 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 07:33 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-15 14:31 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 14:34 -0600
Re: f.) for Gorth Paul Rubin <no.email@nospam.invalid> - 2016-12-15 16:20 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-15 16:46 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-17 09:23 -0800
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-19 02:56 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-16 08:10 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-16 10:00 -0600
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-18 10:32 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-19 03:22 -0600
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-16 14:14 +0100
Re: f.) for Gorth Bernd Paysan <bernd@net2o.de> - 2016-12-19 19:41 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-20 03:02 -0600
Re: f.) for Gorth mhx@iae.nl - 2016-12-20 01:27 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-20 12:35 +0000
Re: f.) for Gorth Charles Montgomery <cgm@physics.utoledo.edu> - 2016-12-20 21:23 -0500
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-21 07:29 +0000
Re: f.) for Gorth Charles Montgomery <cgm@physics.utoledo.edu> - 2016-12-21 22:24 -0500
Re: f.) for Gorth "David N. Williams" <williams@umich.edu> - 2016-12-22 08:10 -0500
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-22 17:39 +0000
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-15 12:53 +0100
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-15 05:59 -0600
Re: f.) for Gorth "Robert L." <No_spamming@noWhere_7073.org> - 2017-01-03 16:15 +0000
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-14 17:06 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-18 10:58 +1100
Re: f.) for Gorth Paul Rubin <no.email@nospam.invalid> - 2016-12-17 17:26 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-19 13:16 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 19:19 -0800
Re: f.) for Gorth john <anon@example.com> - 2016-12-19 11:03 +0000
Re: f.) for Gorth Mark Wills <markwills1970@gmail.com> - 2016-12-20 01:46 -0800
Re: f.) for Gorth john <anon@example.com> - 2016-12-20 12:14 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 17:34 -0800
Re: f.) for Gorth Paul Rubin <no.email@nospam.invalid> - 2016-12-18 19:25 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 19:45 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-22 11:32 +1100
Re: f.) for Gorth Bernd Paysan <bernd@net2o.de> - 2017-01-03 19:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-03 22:13 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-04 23:03 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-06 22:52 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-07 22:45 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-07 17:23 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-08 09:13 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2017-01-08 17:10 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2017-01-09 10:22 +0000
Re: f.) for Gorth stephen@mpeforth.com - 2017-01-08 07:00 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-20 14:09 +0200
Re: f.) for Gorth Matthias Trute <matthias.trute@gmail.com> - 2017-01-11 01:14 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-07 12:26 +0100
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-08 10:21 +1100
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-20 15:45 +0100
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-20 15:33 +0000
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-22 11:37 +1100
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-22 14:19 +0100
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-23 12:11 +1100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-22 17:49 -0800
Re: f.) for Gorth "HAA" <someone@microsoft.com> - 2016-12-23 20:41 +1100
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-20 14:21 +0200
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-15 22:31 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-16 18:26 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 16:41 -0800
Re: f.) for Gorth stephen@mpeforth.com - 2016-12-20 02:20 -0800
Re: f.) for Gorth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-12-20 13:04 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 17:27 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-17 10:36 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-17 11:51 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-18 19:35 -0800
Re: f.) for Gorth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-12-19 14:17 +0100
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-19 10:10 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-19 20:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-19 18:11 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-19 19:03 -0800
Re: f.) for Gorth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-20 08:10 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 18:05 -0800
Re: f.) for Gorth - what is a number? Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-12-21 09:04 +0000
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-20 15:26 +0000
Re: f.) for Gorth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-20 11:30 -0600
Language stds (was Re: f.) for Gorth) Alex <alex@rivadpm.com> - 2016-12-20 19:49 +0000
Re: Language stds (was Re: f.) for Gorth) john <anon@example.com> - 2016-12-20 20:06 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-20 17:52 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-21 13:47 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-21 20:46 -0800
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-22 14:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-22 07:06 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-22 07:21 -0800
Re: f.) for Gorth Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-12-23 07:41 +0000
Re: f.) for Gorth Alex <alex@rivadpm.com> - 2016-12-23 08:33 +0000
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-23 18:22 -0800
Re: f.) for Gorth Julian Fondren <julian.fondren@gmail.com> - 2016-12-23 20:28 -0800
Re: f.) for Gorth hughaguilar96@gmail.com - 2016-12-26 18:30 -0800
Language stds (Re: f.) for Gorth) "HAA" <someone@microsoft.com> - 2016-12-24 12:12 +1100
Re: Language stds (Re: f.) for Gorth) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-24 03:28 -0600
Re: Language stds (Re: f.) for Gorth) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-24 10:02 -0600
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-24 16:13 -0800
Re: Language stds (Re: f.) for Gorth) Alex <alex@rivadpm.com> - 2016-12-24 18:13 +0000
Re: Language stds (Re: f.) for Gorth) "HAA" <someone@microsoft.com> - 2016-12-28 09:24 +1100
Re: Language stds (Re: f.) for Gorth) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-27 17:10 -0600
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-27 22:58 -0800
Re: Language stds (Re: f.) for Gorth) "HAA" <someone@microsoft.com> - 2016-12-29 10:12 +1100
Re: Language stds (Re: f.) for Gorth) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-29 17:03 -0800
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-29 19:35 -0800
Re: Language stds (Re: f.) for Gorth) Howerd <howerdo@yahoo.co.uk> - 2016-12-30 05:27 -0800
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-30 19:11 -0800
Re: Language stds (Re: f.) for Gorth) hughaguilar96@gmail.com - 2016-12-31 06:42 -0800
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-20 15:26 +0000 |
| Message-ID | <o3bigs$8vg$1@dont-email.me> |
| In reply to | #53438 |
On 12/20/2016 02:11, hughaguilar96@gmail.com wrote: > On Monday, December 19, 2016 at 1:33:57 PM UTC-7, Alex wrote: >> For someone who has already dismissed ANS Forth as useless, I am >> amazed that you need to continue to tell everyone, at length and >> every day, that it's grinding your gears. We get it. You can stop >> now. > > Elizabeth Rather and her sycophants can stop claiming to be the > leaders of the Forth community -- now would be a good time. I've never seen anyone here claim such a thing. I suspect you don't like them disagreeing with you. It's not comp.lang.hugh though. > > The only way that Forth can succeed is for ANS-Forth to be defeated > --- ANS-Forth was a steaming pile of salesmanship in 1994 and it > continues to reek decades later --- it is time to press the flush > lever and send ANS-Forth to its proper destination. I see you've failed in your decades long mission then. > > In the 1980s the Forth enthusiasts did a lot of talk about how in > Forth "anything is possible." The irony of this is that ANS-Forth > came out in 1994 with a lot of ambiguity, meaning that almost any > Forth implementation was ANS-Forth compliant, even if these > implementations were contradictory to each other. That's not logical. Please point out any two systems where they are ANS compliant yet "contradictory". The more serious point here is that standards are almost always ambiguous since they are (largely) written in English. And many standards are written in the sure knowledge that they cover many implementations on different platforms, and that they may suffer from imprecision of specification as a result. That's an acceptable outcome, since to have a standard few or none can meet is pointless. A good example of this is NFS. Here's the charter ---- The working group has found that as NFSv4 implementations mature and deployments continue, clarifications to existing RFCs are needed. These clarifications assist vendors in delivering quality and interoperable implementations. The working group is chartered with the vetting of the issues and determining correctness of submitted errata. ---- NFS is hugely successful, and has seen off all other file protocols excepting Microsoft's proprietary SMB. There are hundreds (possibly thousands) of working client and server implementations, on a variety of platforms. But it's still not a perfect standard. It has ambiguities and errors. ANS Forth works on the same principles; it is more important to codify running code that works than to propose and maintain some unattainable or restrictive definition, simply to satsify OCD sufferers like you that loathe untidy ambiguities. > > Now in 2016, despite the fact that "anything is possible," the > Forth-200x committee are incapable of writing basic software. For > example, they don't know how to convert floats into strings. VFX also > has a bug in its outer-interpreter code that converts strings into > floats. That is pathetic! I write Forth code that works correctly, You don't. In fact, the statement is provably wrong; only last week you posted up a bug correction to your own code. > but the Forth-200x committee ignores it because Elizabeth Rather says > that I'm not a Forth programmer.That is pathetic! ANS-Forth and > Forth-200x must be flushed if Forth is going to be taken seriously in > the real world. > You're on a loser here. The real world (and the people in it, like me, Elizabeth and your huge cast of hate figures) will always fail to deliver to your satisfaction. The rest of us just get on with it, and make the effort to tidy up imperfect yet useful standards when there's a breakage that needs dealt with. And we do it without disagreeing with each other to the point where we sound like psychotic nutjobs. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-20 11:30 -0600 |
| Message-ID | <yMqdnS2RgZdY98TFnZ2dnUU7-RPNnZ2d@supernews.com> |
| In reply to | #53449 |
Alex <alex@rivadpm.com> wrote: > The more serious point here is that standards are almost always > ambiguous since they are (largely) written in English. And many > standards are written in the sure knowledge that they cover many > implementations on different platforms, and that they may suffer > from imprecision of specification as a result. It's a tough one. I imagine that if you knew nothing about Forth at all but tried to implement the standard, the result might be rather odd. You have to assume some level of knowledge on the part of any reader. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-20 19:49 +0000 |
| Subject | Language stds (was Re: f.) for Gorth) |
| Message-ID | <o3c1u6$6dl$1@dont-email.me> |
| In reply to | #53451 |
On 12/20/2016 17:30, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: > >> The more serious point here is that standards are almost always >> ambiguous since they are (largely) written in English. And many >> standards are written in the sure knowledge that they cover many >> implementations on different platforms, and that they may suffer >> from imprecision of specification as a result. > > It's a tough one. I imagine that if you knew nothing about Forth at > all but tried to implement the standard, the result might be rather > odd. You have to assume some level of knowledge on the part of any > reader. > > Andrew. > Implementation is what a standard shouldn't set out to describe; that's where a specification is employed. Some argue that a specification is a standard; the wikipedia article takes this stance in the opening paragraph https://en.wikipedia.org/wiki/Programming_language_specification but then describes specifications and standards as distinct entities (which is my position). A specification "states a precise requirement" or is "a detailed description of the design and materials used to make something". ANS Forth doesn't do that. A standard defines "something used as a measure, norm, or model in comparative evaluations"; which is exactly what we do when we declare X to meet the ANS Forth standard. Whatever the semantics & dictionary definitions of this, few language standards have is the rigour that Hugh requires. And most would be hard to implement without knowledge. I can't imagine writing a C++ compiler from the standard. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | john <anon@example.com> |
|---|---|
| Date | 2016-12-20 20:06 +0000 |
| Subject | Re: Language stds (was Re: f.) for Gorth) |
| Message-ID | <MPG.32c39f828d9881f69896e0@news.virginmedia.com> |
| In reply to | #53452 |
In article <o3c1u6$6dl$1@dont-email.me>, alex@rivadpm.com says... > Implementation is what a standard shouldn't set out to describe; that's > where a specification is employed. Some argue that a specification is a > standard; the wikipedia article takes this stance in the opening > paragraph > https://en.wikipedia.org/wiki/Programming_language_specification but > then describes specifications and standards as distinct entities (which > is my position). > Alex would be correct here. You might for example write a program in "standard" C but that program might be specified using another tool. so you might use the program specification langiage to define the program or system (such as Z ... https://en.wikipedia.org/wiki/Z_notation) but even Z cannot guarantee your implementation of the specification is correct unless you write it to a specific standard. (You will note there is an ISO "standard" for Z itself also ) -- john ========================= http://johntech.co.uk "Bleeding Edge Forum" http://johntech.co.uk/forum/ =========================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-20 17:52 -0800 |
| Message-ID | <728a4560-2bf7-49f8-a701-155cdcbde6cc@googlegroups.com> |
| In reply to | #53449 |
On Tuesday, December 20, 2016 at 8:26:43 AM UTC-7, Alex wrote: > On 12/20/2016 02:11, hughaguilar96@gmail.com wrote: > > In the 1980s the Forth enthusiasts did a lot of talk about how in > > Forth "anything is possible." The irony of this is that ANS-Forth > > came out in 1994 with a lot of ambiguity, meaning that almost any > > Forth implementation was ANS-Forth compliant, even if these > > implementations were contradictory to each other. > > That's not logical. Please point out any two systems where they are ANS > compliant yet "contradictory". The ANS-Forth documentation (6.1.1550) for FIND says this: "For a given string, the values returned by FIND while compiling may differ from those returned while not compiling." The word "may" is a red flag indicating ambiguity. This was a political concession. Elizabeth Rather was trying to appease Charles Moore to allow his cmForth to be ANS-Forth compliant, and she had noticed that FIND returns different values depending upon STATE at the time that FIND is executed. This was stupid because Charles Moore didn't want cmForth to be ANS-Forth compliant --- Charles Moore had no interest in any of his Forth systems being ANS-Forth compliant --- he was ignoring her. This was also stupid because it wasn't necessary. The reason why FIND returns different values depending upon STATE at the time that FIND is executed, is because colon changes CONTEXT --- then semicolon changes CONTEXT back again --- so FIND behaves differently inside the colon word as compared to outside, but this is just ordinary Forth because FIND has always relied on CONTEXT for its vocabulary. Now we have gForth that has a FIND that returns different values depending upon STATE at the time that FIND is executed --- this is just bizarre --- gForth is contradictory to all other ANS-Forth systems. Another ambiguity in ANS-Forth is that Standard words (such as IF etc.) may or may not be immediate. This is ambiguous --- they should have been standardized as immediate --- we have contradiction between ANS-Forth systems, such as VFX where IF is non-immediate and SwiftForth where IF is immediate, and gForth where ticking IF aborts the system. I can fix this problem with my disambiguifiers. With my disambiguifiers, gForth, VFX, and SwiftForth (and, afaik, all other ANS-Forth systems) work the same, and they work in a manner that makes sense (words such as IF that were immediate in Forth-83 are immediate again). My disambiguifiers don't totally guarantee that ANS-Forth is disambiguified however. Once again, the ANS-Forth documentation (6.1.1550) for FIND says this: "For a given string, the values returned by FIND while compiling may differ from those returned while not compiling." The ANS-Forth document doesn't say that this problem only occurs with IF etc. --- all the ANS-Forth systems that I have tested have the same set of problem words, all of which I disambiguified (there are about 50) --- it is theoretically possible for this problem to occur with any "given string" however, so an insane ANS-Forth compiler-writer who wants to be even more bizarre than gForth could pathologically extend this idea to other words that I haven't disambiguified.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-21 13:47 +0000 |
| Message-ID | <o3e135$a3r$1@dont-email.me> |
| In reply to | #53458 |
On 12/21/2016 01:52, hughaguilar96@gmail.com wrote: > On Tuesday, December 20, 2016 at 8:26:43 AM UTC-7, Alex wrote: >> On 12/20/2016 02:11, hughaguilar96@gmail.com wrote: >>> In the 1980s the Forth enthusiasts did a lot of talk about how >>> in Forth "anything is possible." The irony of this is that >>> ANS-Forth came out in 1994 with a lot of ambiguity, meaning that >>> almost any Forth implementation was ANS-Forth compliant, even if >>> these implementations were contradictory to each other. >> >> That's not logical. Please point out any two systems where they are >> ANS compliant yet "contradictory". > > The ANS-Forth documentation (6.1.1550) for FIND says this: "For a > given string, the values returned by FIND while compiling may differ > from those returned while not compiling." > > The word "may" is a red flag indicating ambiguity. > > This was a political concession. Elizabeth Rather was trying to > appease Charles Moore to allow his cmForth to be ANS-Forth compliant, > and she had noticed that FIND returns different values depending upon > STATE at the time that FIND is executed. > > This was stupid because Charles Moore didn't want cmForth to be > ANS-Forth compliant --- Charles Moore had no interest in any of his > Forth systems being ANS-Forth compliant --- he was ignoring her. Stop baring your arse in public Hugh. It destroys any reasonable argument you might have had. > > This was also stupid because it wasn't necessary. The reason why FIND > returns different values depending upon STATE at the time that FIND > is executed, is because colon changes CONTEXT --- then semicolon > changes CONTEXT back again --- so FIND behaves differently inside the > colon word as compared to outside, but this is just ordinary Forth > because FIND has always relied on CONTEXT for its vocabulary. CONTEXT is not defined in ANS Forth; you are confusing standardisation with implementation. > > Now we have gForth that has a FIND that returns different values > depending upon STATE at the time that FIND is executed --- this is > just bizarre --- gForth is contradictory to all other ANS-Forth > systems. But this isn't contradictory, since the standard explicitly notes that FIND may return a different XT while compiling. Therefore gForth is ANS compliant. Where is the contradiction? > > Another ambiguity in ANS-Forth is that Standard words (such as IF > etc.) may or may not be immediate. This is ambiguous --- they should > have been standardized as immediate --- we have contradiction between > ANS-Forth systems, such as VFX where IF is non-immediate and > SwiftForth where IF is immediate, and gForth where ticking IF aborts > the system. > > I can fix this problem with my disambiguifiers. With my > disambiguifiers, gForth, VFX, and SwiftForth (and, afaik, all other > ANS-Forth systems) work the same, and they work in a manner that > makes sense (words such as IF that were immediate in Forth-83 are > immediate again). > > My disambiguifiers don't totally guarantee that ANS-Forth is > disambiguified however. Once again, the ANS-Forth documentation > (6.1.1550) for FIND says this: "For a given string, the values > returned by FIND while compiling may differ from those returned while > not compiling." The ANS-Forth document doesn't say that this problem > only occurs with IF etc. --- all the ANS-Forth systems that I have > tested have the same set of problem words, all of which I > disambiguified (there are about 50) --- it is theoretically possible > for this problem to occur with any "given string" however, so an > insane ANS-Forth compiler-writer who wants to be even more bizarre > than gForth could pathologically extend this idea to other words that > I haven't disambiguified. > Again, these systems are ANS Forth compliant. There is no inconsistency. So let's say you want to remove this ambiguity. (You've attempted to do so with your "disambiguifiers"; but contrary to your stated assertions that they work on all ANS Forth systems, they fail to work correctly when they are POSTPONEd on my system. I haven't spent any time attempting to debug, since I can't see why the problem they are intended to solve might be important.) What changes would you make to the standard? What systems would that then disqualify from claiming ANS Forth compliance? Would this change anything for the better? Would it make it hard to modify gForth to comply with your requirement, and might disqualify other current and future systems? Will your proposal get support? For the record, I support the decision to cut you out of the standards process entirely & I cheered when you got blocked from the Forth200x mailing group for your stupid abusive behaviour. Standards are born out of cooperation and community, not out of the yelling & shouting of one individual who wants to dictate a solution, and then attempts to destroy the reputation and work of others when they fail to do as he demands. Why should they listen to you when it's obvious you hate them and all the things they've worked for? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-21 20:46 -0800 |
| Message-ID | <caeeda0c-4a19-4287-a481-d3dc238447fe@googlegroups.com> |
| In reply to | #53465 |
On Wednesday, December 21, 2016 at 6:47:41 AM UTC-7, Alex wrote:
> On 12/21/2016 01:52, hughaguilar96@gmail.com wrote:
> > Another ambiguity in ANS-Forth is that Standard words (such as IF
> > etc.) may or may not be immediate. This is ambiguous --- they should
> > have been standardized as immediate --- we have contradiction between
> > ANS-Forth systems, such as VFX where IF is non-immediate and
> > SwiftForth where IF is immediate, and gForth where ticking IF aborts
> > the system.
> >
> > I can fix this problem with my disambiguifiers. With my
> > disambiguifiers, gForth, VFX, and SwiftForth (and, afaik, all other
> > ANS-Forth systems) work the same, and they work in a manner that
> > makes sense (words such as IF that were immediate in Forth-83 are
> > immediate again).
> >
> > My disambiguifiers don't totally guarantee that ANS-Forth is
> > disambiguified however. Once again, the ANS-Forth documentation
> > (6.1.1550) for FIND says this: "For a given string, the values
> > returned by FIND while compiling may differ from those returned while
> > not compiling." The ANS-Forth document doesn't say that this problem
> > only occurs with IF etc. --- all the ANS-Forth systems that I have
> > tested have the same set of problem words, all of which I
> > disambiguified (there are about 50) --- it is theoretically possible
> > for this problem to occur with any "given string" however, so an
> > insane ANS-Forth compiler-writer who wants to be even more bizarre
> > than gForth could pathologically extend this idea to other words that
> > I haven't disambiguified.
> >
>
> Again, these systems are ANS Forth compliant. There is no inconsistency.
>
> So let's say you want to remove this ambiguity. (You've attempted to do
> so with your "disambiguifiers"; but contrary to your stated assertions
> that they work on all ANS Forth systems, they fail to work correctly
> when they are POSTPONEd on my system. I haven't spent any time
> attempting to debug, since I can't see why the problem they are intended
> to solve might be important.)
Alex McDonald is lying, as usual. My disambiguified words can be postponed. They are just immediate words, and immediate words can be postponed.
The disambiguifiers solve the problem in ANS-Forth of FIND being ambiguous --- FIND behaves differently from one ANS-Forth system to another (VFX, SwiftForth and gForth are all contradictory to each other) --- FIND also solves the problem in ANS-Forth of Standard words (such as IF etc.) being undefined as to whether they are immediate or not (VFX, SwiftForth and gForth are contradictory to each other).
Here is an example of postponing IF in a meta-compiling word without the disambiguifiers:
novice.4th ok
: mmm postpone 2dup postpone > postpone if postpone swap postpone then ; immediate ok
: ttt mmm ; ok
2 3 ttt .s
DATA STACK
top
3 0000:0003
2 0000:0002
ok-2
swap ok-2
ttt ok-2
.s
DATA STACK
top
3 0000:0003
2 0000:0002
ok-2
2drop ok
Now we INCLUDE the novice-package with its disambiguifiers and try again:
: mmm postpone 2dup postpone > postpone if postpone swap postpone then ; immediate
MMM is redefined ok
: ttt mmm ;
TTT is redefined ok
2 3 ttt ok-2
.s
DATA STACK
top
3 0000:0003
2 0000:0002
ok-2
swap ok-2
ttt ok-2
.s
DATA STACK
top
3 0000:0003
2 0000:0002
ok-2
2drop ok
So, it is okay to postpone a disambiguified word. This was under VFX. I don't know of any reason why this would not work under any ANS-Forth system. Alex says: "they fail to work correctly when they are POSTPONEd on my system. I haven't spent any time attempting to debug..." It is apparently his own Forth system that this doesn't work on. So, his Forth system has bugs, and he hasn't spent any time attempting to debug --- instead he blames me for the bugs in his Forth system. Alex McDonald is a jerk!
Alex McDonald has also lost his fake-quotation RfD --- apparently the Forth-200x committee have figured out that he is a jerk and have dropped him. The fake quotations were written by Bernd Paysan, but Bernd Paysan can't put his name on the fake-quotation RfD because he is a member of the Forth-200x committee --- the RfDs have to be written by non-members of the Forth-200x committee in order to fake up the image of Forth-200x being a grassroots project with these RfDs being written by the Forth community. Because of this, Alex McDonald was told to put his name on the RfD and pretend that he wrote it. Because the fake quotations were actually written by Bernd Paysan (committee member) and 100% supported by Anton Ertl (committee chair-person), getting the RfD accepted should have been super-easy --- a slam-dunk from a ladder for Alex McDonald --- but Alex McDonald screwed up this super-easy task and Anton Ertl had to take the RfD away from him. Now the RfD is in limbo --- the Forth-200x committee are looking for some other sycophant to put his name on the RfD and pretend that he wrote it (most likely this will be Julien Fondren).
So, how did Alex McDonald screw up such a super-easy task? Primarily his screw up was that he bragged on comp.lang.forth about how he "does standards for a living." WTF??? The fact that Alex McDonald is getting paid by Forth Inc. to support Forth-200x, really ruins the grass-roots image that Forth Inc. has been trying so hard to fake up. Alex McDonald is an idiot! He should not have bragged about getting paid. The Forth-200x committee could have found a crack-head and paid him $30 to put his name on the RfD, and the crack-head would have been smart enough not to tell anybody on comp.lang.forth that he was getting paid --- but Alex McDonald is not this smart --- so now Alex has lost his RfD and the Forth-200x committee is left hanging.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-22 14:33 +0000 |
| Message-ID | <o3go4t$u8i$1@dont-email.me> |
| In reply to | #53481 |
On 12/22/2016 04:46, hughaguilar96@gmail.com wrote: > On Wednesday, December 21, 2016 at 6:47:41 AM UTC-7, Alex wrote: >> On 12/21/2016 01:52, hughaguilar96@gmail.com wrote: >>> Another ambiguity in ANS-Forth is that Standard words (such as >>> IF etc.) may or may not be immediate. This is ambiguous --- they >>> should have been standardized as immediate --- we have >>> contradiction between ANS-Forth systems, such as VFX where IF is >>> non-immediate and SwiftForth where IF is immediate, and gForth >>> where ticking IF aborts the system. >>> >>> I can fix this problem with my disambiguifiers. With my >>> disambiguifiers, gForth, VFX, and SwiftForth (and, afaik, all >>> other ANS-Forth systems) work the same, and they work in a manner >>> that makes sense (words such as IF that were immediate in >>> Forth-83 are immediate again). >>> >>> My disambiguifiers don't totally guarantee that ANS-Forth is >>> disambiguified however. Once again, the ANS-Forth documentation >>> (6.1.1550) for FIND says this: "For a given string, the values >>> returned by FIND while compiling may differ from those returned >>> while not compiling." The ANS-Forth document doesn't say that >>> this problem only occurs with IF etc. --- all the ANS-Forth >>> systems that I have tested have the same set of problem words, >>> all of which I disambiguified (there are about 50) --- it is >>> theoretically possible for this problem to occur with any "given >>> string" however, so an insane ANS-Forth compiler-writer who wants >>> to be even more bizarre than gForth could pathologically extend >>> this idea to other words that I haven't disambiguified. >>> >> >> Again, these systems are ANS Forth compliant. There is no >> inconsistency. >> >> So let's say you want to remove this ambiguity. (You've attempted >> to do so with your "disambiguifiers"; but contrary to your stated >> assertions that they work on all ANS Forth systems, they fail to >> work correctly when they are POSTPONEd on my system. I haven't >> spent any time attempting to debug, since I can't see why the >> problem they are intended to solve might be important.) > > Alex McDonald is lying, as usual. My disambiguified words can be > postponed. They are just immediate words, and immediate words can be > postponed. Immediacy is handled quite differently in my Forth, and STATE is not used at all, although it's there and correctly set to meet with the ANS standard. In fact, immediacy as a concept doesn't even exist; all the word IMMEDIATE does is to make the word's compile XT be the interpet XT. It's based on conversations Anton Ertl and I had on clf in 2004 (my, doesn't time fly?) https://www.complang.tuwien.ac.at/forth/header-ideas.html > > The disambiguifiers solve the problem in ANS-Forth of FIND being > ambiguous --- FIND behaves differently from one ANS-Forth system to > another (VFX, SwiftForth and gForth are all contradictory to each > other) --- FIND also solves the problem in ANS-Forth of Standard > words (such as IF etc.) being undefined as to whether they are > immediate or not (VFX, SwiftForth and gForth are contradictory to > each other). You keep saying that the standard on FIND is ambiguous. It isn't. It's very clear as to what is allowed, and what is allowed is FIND returning a different XT for compilation and interpretation states. In other words, if you want the right XT, you need to FIND precisely when you need it, not earlier. As an aside, I believe the standard also allows FIND to return different XTs for the same word while compiling. An example, when DUP may have two XTs, one unoptimised and the other optimised; : FOO DUP [ OPTIMISE-ON ] DUP [ OPTIMISE-OFF ] ; This is not an ambiguity, since FIND searches "all the word lists in the search order" and the search order might have been changed by OPTIMISE-ON. So I'll ask again. What changes would you make to the standard? What systems would that then disqualify from claiming ANS Forth compliance? Would this change anything for the better? Would it make it hard to modify gForth to comply with your requirement, and might disqualify other current and future systems? Will your proposal get support? I'd also point you to gForth's FIND-NAME https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Name-token.html. FIND-NAME avoids two problems that FIND has; an unpredictable stack return (2 or 1 stack items depending on success or failure respectively) and rather than an XT it returns a name token (NT) that can be used to derive the possibly distinct compile and interpretation XTs of the word. <snip tests on VFX> > It is apparently his own Forth system that this doesn't > work on. So, his Forth system has bugs, and he hasn't spent any time > attempting to debug --- instead he blames me for the bugs in his > Forth system. Alex McDonald is a jerk! > My system passes the ANS Forth tests https://github.com/gerryjackson/forth2012-test-suite/tree/master and Anton's POSTPONE.FS test. The tests may be incomplete and fail to exercise corner cases, but they are are currently the best indicator we have of compliance. Because my system is using FIND-NAME rather than FIND internally, and because it permits POSTPONEing any word (including those that parse like TO and S") I have currently little interest in debugging your code on my system, since it is designed to fix a problem I don't have. > Alex McDonald has also lost his fake-quotation RfD --- apparently the > blah blah blah blah blah > Your rump is hanging out of your trousers again. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-22 07:06 -0800 |
| Message-ID | <5a4fdd58-6233-462e-b8b4-f067c8a0aa6d@googlegroups.com> |
| In reply to | #53492 |
On Thursday, December 22, 2016 at 7:33:26 AM UTC-7, Alex wrote: > My system passes the ANS Forth tests The ANS-Forth motto: "Anything is possible!"
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-12-22 07:21 -0800 |
| Message-ID | <c73550f2-b66b-4a1b-affd-ce5d3cf5a6e5@googlegroups.com> |
| In reply to | #53493 |
On Thursday, December 22, 2016 at 9:06:04 AM UTC-6, hughag...@gmail.com wrote: > On Thursday, December 22, 2016 at 7:33:26 AM UTC-7, Alex wrote: > > My system passes the ANS Forth tests > > The ANS-Forth motto: "Anything is possible!" Yep. I peeked inside those so-called conformance tests: \ IS IT ANS FORTH? Copyright (C) 1994 Leo Brodie \ (Please stop asking me to write literally everything -- lb) .( Congratulations! Your Forth is 100% ANS compliant!) \ regrettable dependency on .( and \ \ if you get errors about these words, don't worry: you're still ANS You sure sussed these fraudsters out, Hugh. OTOH it was pretty stupid of them to make this absurd test public. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-12-23 07:41 +0000 |
| Message-ID | <o3ikdb$u10$1@dont-email.me> |
| In reply to | #53465 |
On 21/12/2016 13:47, Alex wrote: > So let's say you want to remove this ambiguity. (You've attempted to do > so with your "disambiguifiers"; but contrary to your stated assertions > that they work on all ANS Forth systems, they fail to work correctly > when they are POSTPONEd on my system. I haven't spent any time > attempting to debug, since I can't see why the problem they are intended > to solve might be important.) > Like you, I haven't considered Hugh's "disambiguifiers" important enough to spend any time on but, without taking sides in this argument, I think it is worth identifying why they can't be POSTPONEd on your system. IIRC there has been no hint that they are invalid Forth and so should be able to be POSTPONEd. So either it is an unexpected problem with the disambiguifiers or your system is at fault. My interest is that the Forth test suite might have a hole that needs filling. A simple test using a disambiguifier (a silly name, I'm already sick of typing/pasting it) works on all systems I've tried it on. : if state @ 0= abort" *** no interpretation semantics for: IF ***" postpone if ; immediate \ The disambiguifier : if postpone if ; immediate : x if ." true" else ." false" then ; -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-23 08:33 +0000 |
| Message-ID | <o3inee$6kh$1@dont-email.me> |
| In reply to | #53501 |
On 12/23/2016 07:41, Gerry Jackson wrote: > On 21/12/2016 13:47, Alex wrote: >> So let's say you want to remove this ambiguity. (You've attempted to do >> so with your "disambiguifiers"; but contrary to your stated assertions >> that they work on all ANS Forth systems, they fail to work correctly >> when they are POSTPONEd on my system. I haven't spent any time >> attempting to debug, since I can't see why the problem they are intended >> to solve might be important.) >> > > Like you, I haven't considered Hugh's "disambiguifiers" important enough > to spend any time on but, without taking sides in this argument, I think > it is worth identifying why they can't be POSTPONEd on your system. IIRC > there has been no hint that they are invalid Forth and so should be able > to be POSTPONEd. So either it is an unexpected problem with the > disambiguifiers or your system is at fault. My interest is that the > Forth test suite might have a hole that needs filling. > > A simple test using a disambiguifier (a silly name, I'm already sick of > typing/pasting it) works on all systems I've tried it on. > > : if state @ 0= abort" *** no interpretation semantics for: IF ***" > postpone if ; immediate \ The disambiguifier > : if postpone if ; immediate > : x if ." true" else ." false" then ; > Not all of them fail; the IF example works as do the majority of others. This doesn't; once redeclared POSTPONE fails to generate correct code for parsing words like POSTPONE S" . : postpone state @ 0= abort" *** no interpretation semantics for: POSTPONE ***" postpone postpone ; immediate I'll take a look at it at some point. Time for hobbies is not exactly in huge supply at Chez Alex. Have a good holiday. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-23 18:22 -0800 |
| Message-ID | <14263e2e-5819-4160-a10b-0ed241bb21c7@googlegroups.com> |
| In reply to | #53501 |
On Friday, December 23, 2016 at 12:41:56 AM UTC-7, Gerry wrote:
> I haven't considered Hugh's "disambiguifiers" important enough
> to spend any time on but...
Here is an example:
https://groups.google.com/forum/#!topic/comp.lang.forth/92KNs8p4J6Y
I'm getting criticized here because my MACRO: does late-binding.
My MACRO was originally written to do early-binding. I used FIND to obtain every xt and saved these in an array, rather than saving the source-code. This worked under SwiftForth. Then Ron Aaron tried my code under Gforth and it failed. This was here:
https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D
On Tuesday, November 24, 2009 at 11:37:04 PM UTC-7, ron wrote:
> On Nov 25, 7:38 am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
>
> > I didn't compile your program because it is not ANS-Forth. I don't
> > have iForth and I'm not going to spend the $100 to buy it. I really
> > need ANS-Forth in order to be able to run programs such as this.
>
> I suppose "gforth" is not an ANS-Forth? Your version of the program
> does not compile under gforth 0.7.0:
>
> lc53.f:27: Cannot tick compile-only word (try COMP' ... DROP)
> over ['] >>>;<<< = if 2drop postpone ; immediate exit
> then
Notice the pattern here? I get blamed for everything! It is pretty much impossible to write non-trivial ANS-Forth code that compiles and executes the same on every ANS-Forth --- I get blamed though --- the blame falls on me because I'm writing non-trivial code (as compared to copying code snippets out of "Starting Forth" and posting them on comp.lang.forth like Elizabeth Rather does).
Anton Ertl agrees that I'm no good at ANS-Forth programming:
On Wednesday, November 25, 2009 at 4:14:59 AM UTC-7, Anton Ertl wrote:
> ron <ron@ronware.org> writes:
> >On Nov 25, 8:57=A0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> >> On Nov 24, 11:37=A0pm, ron <r...@ronware.org> wrote:
> >> > lc53.f:27: Cannot tick compile-only word (try COMP' ... DROP)
> ^^^^^^ ^^
> file line
>
> >> > =A0 =A0 =A0 =A0 =A0 =A0 over ['] >>>;<<< =3D if =A02drop =A0postpone ; =
> ...
> >> I don't use gforth. What does that error message mean? What is a
> >> "compile-only word?"
>
> A word without interpretation semantics.
>
> >It doesn't like you taking the address of ";" , though I don't
> >understand why.
>
> Because ";" has no execution or interpretation semantics. The
> execution token returned by ['] represents the execution semantics,
> but since ";" does not have that ...
But wait! Anton Ertl has a solution! This is the kind of awesome ANS-Forth expertise that got him appointed to be the chair-person of the Forth-200x committee!
On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> Hugh Aguilar <hugoaguilar@rosycrew.com> writes:
> >On Nov 25, 4:14=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> >On Nov 25, 8:57=3DA0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> >> >> I don't use gforth. What does that error message mean? What is a
> >> >> "compile-only word?"
> >>
> >> A word without interpretation semantics.
> >>
> >> >It doesn't like you taking the address of ";" , though I don't
> >> >understand why.
> >>
> >> Because ";" has no execution or interpretation semantics. =A0The
> >> execution token returned by ['] represents the execution semantics,
> >> but since ";" does not have that ...
> >
> >I don't understand how a word can not have execution semantics.
>
> That's quite simple: By not defining execution semantics in the
> definition of the word in the standard document. Look up the
> definition of ";" in the standard, and you will see that there is no
> "Execution:" section there; and there are other labeled sections
> there, so the "omitted label" sentence of 3.4.3.1 does not apply.
>
> >For immediate words (IF, ;, etc.)
>
> IF and ";" are not immediate words in the standard. A system can
> implement them as immediate words, but a program cannot rely on their
> immediacy.
>
> >I looked up ['] in the ANS-Forth document and it says:
> >
> >"Place name's execution token xt on the stack."
>
> What's the execution token of a word that has no execution semantics.
>
> Hmm, since you think that ";" is immediate, I guess you want an
> execution token that, when executed, performs the compilation
> semantics. You can get that as follows. Before the rest of the
> program, define:
>
> : ; postpone ; ; immediate
>
> Now you have an immediate ";" with an execution semantics that's the
> same as the compilation semantics, and you can tick it.
>
> >What I am saying is that I didn't have any warning that what I was
> >doing in MACRO: was going to be a problem.
>
> A system that would tell us all non-standard usages would be nice, but
> we don't have that. For now the solution is to test on as many
> systems as possible.
>
> - anton
Here is Anton Ertl's code:
: ; postpone ; ; immediate
Does that look familiar? Here is one of my disambiguifiers in the novice-package:
: if
state @ 0= abort" *** no interpretation semantics for: IF ***"
postpone if ; immediate
So, Anton Ertl actually invented the disambiguifiers in November of 2009.
But wait! Bernd Paysan also invented the disambiguifiers.
https://bernd-paysan.de/mini-oof.html
------------------------------------------------------------------------------------
Note: this early binding means that the xt you have assigned to the method may not have non-default compilation semamtics applied with SET-COMPILER (e.g. in VFX Forth). Example: You want to perform the execution semantics of IF in a method
:noname ( -- if-sys ) postpone IF ; some-class defines if-method
------------------------------------------------------------------------------------
So, the disambiguifiers are well known --- my only contribution was the catchy "disambiguifier" name --- but everybody hates the word "disambiguifier" because it shines a spotlight on the fact that ANS-Forth is ambiguous.
Getting back to Alex Wegel's criticism of my MACRO: using late-binding --- now that I have the disambiguifiers I could theoretically rewrite MACRO: to use early-binding.
I'm not going to do that this upcoming release of the novice package (most likely this weekend). I may not do it at all. It is pointless for me to program in ANS-Forth when I can't ever become an ANS-Forth programmer --- no matter what I do, one or the other Alex will say that it is "crap."
Programming in ANS-Forth is a waste of time --- I need to just focus on getting Straight Forth implemented --- ANS-Forth needs to be flushed; it is a hopeless mess of ambiguity and idiocy.
Straight Forth doesn't need disambiguifiers because it is not ambiguous.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-12-23 20:28 -0800 |
| Message-ID | <7444a86e-68a5-4233-a493-02e51e6298af@googlegroups.com> |
| In reply to | #53514 |
On Friday, December 23, 2016 at 8:22:33 PM UTC-6, hughag...@gmail.com wrote: > > Here is an example: > https://groups.google.com/forum/#!topic/comp.lang.forth/92KNs8p4J6Y > I'm getting criticized here because my MACRO: does late-binding. > Be less neurotic. MACRO: is annoying because it behaves like other languages instead of like Forth. And Forth's ordered dictionary is actually a very nice feature of the language, which makes it much easier to deal with names what would otherwise be 'global'. On the one hand idiomatic Forth requires you to come up with lots of names, which is *hard*; on the other hand Forth frees you to use short and easy names without worrying so much that someone somewhere else and sometime else may want to use that same name. You're not the only person who's written a lot of code with this MACRO: problem. Wil Baden wrote an entire system that extensively used EVALUATE, even IIRC in cases like : 2+ S" 2 +" EVALUATE ; IMMEDIATE Wil Baden's words like PLACE TUCK SKIP &c are also nearly an addendum to the standard, they're so widely available in Forth systems. > My MACRO was originally written to do early-binding. I used FIND to obtain every xt and saved these in an array, rather than saving the source-code. This worked under SwiftForth. Then Ron Aaron tried my code under Gforth and it failed. This was here: > https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D What you should have done was use POSTPONE The point of that thread: use POSTPONE Don't use it in order to make your original wrong idea work; use it *instead* of your original idea. > Notice the pattern here? I get blamed for everything! If you go into panic attacks over Forth code running across Forth systems, this might not be the language for you. That might be your real problem. You did some work once and you have some nostalgia blinders but really you seem to hate everything about the language. Have you tried Haskell? (Wil Baden again: "When you've seen one Forth, you've seen one Forth.") > > I'm not going to do that this upcoming release of the novice package (most likely this weekend). I may not do it at all. It is pointless for me to program in ANS-Forth when I can't ever become an ANS-Forth programmer --- no matter what I do, one or the other Alex will say that it is "crap." > OK, Haskell allows too much freedom of expression, so there's still the potential for someone to say that your code is crap. Have you tried Java? -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-26 18:30 -0800 |
| Message-ID | <36abf14c-c1dc-4b72-87b3-14abf42e0b69@googlegroups.com> |
| In reply to | #53514 |
On Friday, December 23, 2016 at 7:22:33 PM UTC-7, hughag...@gmail.com wrote: > On Friday, December 23, 2016 at 12:41:56 AM UTC-7, Gerry wrote: > > I haven't considered Hugh's "disambiguifiers" important enough > > to spend any time on but... > > Here is an example: > https://groups.google.com/forum/#!topic/comp.lang.forth/92KNs8p4J6Y > I'm getting criticized here because my MACRO: does late-binding. > ... > Getting back to Alex Wegel's criticism of my MACRO: using late-binding --- now that I have the disambiguifiers I could theoretically rewrite MACRO: to use early-binding. > > I'm not going to do that this upcoming release of the novice package (most likely this weekend). I may not do it at all. It is pointless for me to program in ANS-Forth when I can't ever become an ANS-Forth programmer --- no matter what I do, one or the other Alex will say that it is "crap." > > Programming in ANS-Forth is a waste of time --- I need to just focus on getting Straight Forth implemented --- ANS-Forth needs to be flushed; it is a hopeless mess of ambiguity and idiocy. > > Straight Forth doesn't need disambiguifiers because it is not ambiguous. Well, I went ahead and rewrote MACRO: to do early-binding rather than late-binding. The code is posted here: https://groups.google.com/forum/#!topic/comp.lang.forth/92KNs8p4J6Y This will be in the novice-package to be released in a few days. Given the disambiguifiers, an early-binding MACRO: was reasonably straight-forward to write. It wasn't totally easy --- it took me a full day --- but it wasn't as complicated as some of the code in the novice-package. Gerry knows ANS-Forth better than most. A lot of his code is quite impressive. :-) Sometimes though, he seems a little bit slow --- he should have been able to understand the disambiguifiers and write an early-binding MACRO: of his own --- I would really expect that anybody who claims to be an ANS-Forth expert should be able to do this. Gerry has criticized my coined word "disambiguifier" as being hard to spell --- he needs to just get used to it, as it will be seen a lot in any discussion of ANS-Forth --- verily, disambiguifiers are the heart and soul of ANS-Forth!
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-24 12:12 +1100 |
| Subject | Language stds (Re: f.) for Gorth) |
| Message-ID | <o3ki28$1p4d$1@gioia.aioe.org> |
| In reply to | #53465 |
Alex wrote: > ... > Standards are born out of cooperation and community, Whatever their lofty statements of intent and inclusion, standards are political processes that necessarily includes vendors and leadership with power of veto. Whatever concessions they may make to the 'community' you can be assured it won't be at their disadvantage. Standards work when you have a usership that has little choice but to comply. That isn't the case with Forth where standards are largely optional and you can get by with a small set of words and reasonable level of skill. > not out of the > yelling & shouting of one individual who wants to dictate a solution, > and then attempts to destroy the reputation and work of others when they > fail to do as he demands. That would include Forth's inventor who faced with the choice of staying and being voted down, chose to leave Forth-94 and has been severely critical ever since. He may have more cause to be disappointed considering Forth has been taken in the opposite direction to what he intended.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-24 03:28 -0600 |
| Subject | Re: Language stds (Re: f.) for Gorth) |
| Message-ID | <Leedneduid5fosPFnZ2dnUU7-XGdnZ2d@supernews.com> |
| In reply to | #53513 |
HAA <someone@microsoft.com> wrote: > Alex wrote: >> ... >> Standards are born out of cooperation and community, > > Whatever their lofty statements of intent and inclusion, standards > are political processes that necessarily includes vendors and > leadership with power of veto. Please describe this power of veto, and how it is enforced. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-12-24 10:02 -0600 |
| Subject | Re: Language stds (Re: f.) for Gorth) |
| Message-ID | <NvOdncUwz-ifAcPFnZ2dnUU7-R3NnZ2d@supernews.com> |
| In reply to | #53513 |
On 12/23/16 7:12 PM, HAA wrote: > Alex wrote: >> ... >> Standards are born out of cooperation and community, > > Whatever their lofty statements of intent and inclusion, standards > are political processes that necessarily includes vendors and > leadership with power of veto. Whatever concessions they may > make to the 'community' you can be assured it won't be at their > disadvantage. Standards work when you have a usership that > has little choice but to comply. That isn't the case with Forth > where standards are largely optional and you can get by with > a small set of words and reasonable level of skill. > >> not out of the >> yelling & shouting of one individual who wants to dictate a solution, >> and then attempts to destroy the reputation and work of others when they >> fail to do as he demands. > > That would include Forth's inventor who faced with the choice of > staying and being voted down, chose to leave Forth-94 and has > been severely critical ever since. He may have more cause to > be disappointed considering Forth has been taken in the opposite > direction to what he intended. It's really a matter of what one's objectives are. Vendors and free system maintainers have an obligation to a body of users, many of whom have commercial projects of many years standing that they depend upon for their livlihood and that of their employers. Moving forward to better standards must consider the needs of those users, but be done with minimal disruption to those existing systems. Individuals who don't have those obligations often feel different motivations. In the case of Chuck, we have a creative genius whose motivation is to explore new ideas and techniques; with no obligations to any body of users, he does not need standards. All of those motivations are valid and genuine, but a standards group should appropriately be concerned with users, who are their main constituents. Cheers, Elizabeth -- Elizabeth R. Conklin FORTH, Inc. 6080 Center Drive, Suite 600 Los Angeles, CA 90045 USA
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-24 16:13 -0800 |
| Subject | Re: Language stds (Re: f.) for Gorth) |
| Message-ID | <7ffc5c05-36ef-498c-9162-de24da5b31ad@googlegroups.com> |
| In reply to | #53520 |
On Saturday, December 24, 2016 at 9:02:16 AM UTC-7, Elizabeth D. Rather wrote: > On 12/23/16 7:12 PM, HAA wrote: > > Alex wrote: > >> ... > >> Standards are born out of cooperation and community, > > > > Whatever their lofty statements of intent and inclusion, standards > > are political processes that necessarily includes vendors and > > leadership with power of veto. Whatever concessions they may > > make to the 'community' you can be assured it won't be at their > > disadvantage. Standards work when you have a usership that > > has little choice but to comply. That isn't the case with Forth > > where standards are largely optional and you can get by with > > a small set of words and reasonable level of skill. > > > >> not out of the > >> yelling & shouting of one individual who wants to dictate a solution, > >> and then attempts to destroy the reputation and work of others when they > >> fail to do as he demands. > > > > That would include Forth's inventor who faced with the choice of > > staying and being voted down, chose to leave Forth-94 and has > > been severely critical ever since. He may have more cause to > > be disappointed considering Forth has been taken in the opposite > > direction to what he intended. The only reason why ANSI certified Elizabeth Rather's toy language was because Charles Moore's name was listed as a contributor in the document. Nobody at ANSI actually knows Forth --- all they know is that Forth was invented by Charles Moore --- when they saw his name on the document, they rubber-stamped it. Elizabeth Rather is a professional name-dropper. She has no accomplishments of her own --- she has made a career out of telling everybody that she was associated with Charles Moore in the 1970s and that this makes her the "leading expert" on Forth --- she also tells a lot of big lies about how she hob-nobs with multiple Nobel Peace Prize winners, hob nobs with Barack Obama's family in Hawaii (prior to her having to leave Hawaii because of the attempted-assassination issue), works for NASA, etc.. Elizabeth Rather's "association" with Charles Moore was just that she was his girlfriend --- he dumped her and found another woman, who he was happily married to until she eventually passed away --- Elizabeth Rather has spent the rest of her life stalking her ex-boyfriend in so much as she tries to take credit for his accomplishments back in the 1970s. Everything that Elizabeth Rather says is a lie --- when she goes to Hell, the whole place will reek of flaming bullshit for 1000 years, and everybody will want to leave. > It's really a matter of what one's objectives are. Vendors and free > system maintainers have an obligation to a body of users, many of whom > have commercial projects of many years standing that they depend upon > for their livlihood and that of their employers. Moving forward to > better standards must consider the needs of those users, but be done > with minimal disruption to those existing systems. Individuals who don't > have those obligations often feel different motivations. In the case of > Chuck, we have a creative genius whose motivation is to explore new > ideas and techniques; with no obligations to any body of users, he does > not need standards. All of those motivations are valid and genuine, but > a standards group should appropriately be concerned with users, who are > their main constituents. The only Forth system that was widely used for professional programming in the early 1990s was UR/Forth from LMI. When ANS-Forth became the Standard, they went from being the leader in the industry to being a non-standard wanna-be --- LMI gave up on Forth --- that was your primary goal with ANS-Forth; to pull the rug out from under the competition. > Elizabeth R. Conklin > FORTH, Inc. > 6080 Center Drive, Suite 600 > Los Angeles, CA 90045 > USA I notice that you are using your real name now. Apparently using your maiden name on comp.lang.forth didn't prevent the assassins from finding you in Hawaii.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-24 18:13 +0000 |
| Subject | Re: Language stds (Re: f.) for Gorth) |
| Message-ID | <o3mdpl$qlo$1@dont-email.me> |
| In reply to | #53513 |
On 12/24/2016 01:12, HAA wrote: > Alex wrote: >> ... Standards are born out of cooperation and community, > > Whatever their lofty statements of intent and inclusion, standards > are political processes that necessarily includes vendors and > leadership with power of veto. Whatever concessions they may make to > the 'community' you can be assured it won't be at their disadvantage. > Standards work when you have a usership that has little choice but to > comply. That isn't the case with Forth where standards are largely > optional and you can get by with a small set of words and reasonable > level of skill. This type of standard is commonly called "de facto" and it really isn't a standard at all; more a market dominance that enforces compliance. Examples include Microsoft SMB or Amazon S3. But even the heavyweights have their hands tied. A whole ecosystem has sprung up around these de facto standrads, and radical changes would be foolish. De jure standards are processes that include vendors and some software standards also include open source or free software practioners. No standards body I know has a leadership with a power of veto; quite the reverse, and most (certainly all those I'm on) have a 1 member 1 vote constitution, regardless of their company's size or user base. But you are correct in one respect; nobody wants a standard to disadvantage their user base, which is why they are often messy & sometimes complex definitions. A small set of words and a reasonable level of skill don't build systems that are interoperable; adhering to standards does that. > >> not out of the yelling & shouting of one individual who wants to >> dictate a solution, and then attempts to destroy the reputation and >> work of others when they fail to do as he demands. > > That would include Forth's inventor who faced with the choice of > staying and being voted down, chose to leave Forth-94 and has been > severely critical ever since. He may have more cause to be > disappointed considering Forth has been taken in the opposite > direction to what he intended. > That was his choice. Being a lone voice is difficult in committee, but it's better being heard and sometimes rejected than not being heard at all. The disappointment of one is to be weighed against the satisfaction of many. Interestingly enough, it was partly Charles Moore's cmForth that influenced the Forth standard committee re FIND and introduced the ambiguities that so hacks Hugh off. -- Alex
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web