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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2016-12-08 18:53 -0500 |
| Message-ID | <20161208185330.6d26b935@_> |
| In reply to | #53186 |
On Thu, 8 Dec 2016 08:12:34 +0000 Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > On 08/12/2016 03:49, hughaguilar96@gmail.com wrote: > > Other languages use some kind of prefix or suffix to indicate > > hexadecimal --- we have $ in Pascal and 0x in C. > > Forth 2012/20XX has prefixes: > > # for decimal numbers > $ for hex > % for binary > > See section 3.4.1.3 in http://forth-standard.org/standard/usage > Why are # $ % number prefixes instead of standalone Forth words? I.e., why aren't they followed by a space? The parsing would seem to be more C style than Forth. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2016-12-09 00:01 +0000 |
| Message-ID | <o2cs6t$2oe$1@dont-email.me> |
| In reply to | #53208 |
On 12/8/2016 23:53, Rod Pemberton wrote: > On Thu, 8 Dec 2016 08:12:34 +0000 > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > >> On 08/12/2016 03:49, hughaguilar96@gmail.com wrote: >>> Other languages use some kind of prefix or suffix to indicate >>> hexadecimal --- we have $ in Pascal and 0x in C. >> >> Forth 2012/20XX has prefixes: >> >> # for decimal numbers >> $ for hex >> % for binary >> >> See section 3.4.1.3 in http://forth-standard.org/standard/usage >> > > Why are # $ % number prefixes instead of standalone Forth words? I.e., > why aren't they followed by a space? The parsing would seem to be more > C style than Forth. > > > Rod Pemberton > Because either # 123 has # parse 123, or it changes the current base without being able to restore it, and is equivalent to DECIMAL 123. Neither is desirable. (And # is already a word.) -- Alex
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-09 12:17 +0100 |
| Message-ID | <o2e3rf$q14$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53209 |
In article <o2cs6t$2oe$1@dont-email.me>, Alex <alex@rivadpm.com> wrote: >On 12/8/2016 23:53, Rod Pemberton wrote: >> On Thu, 8 Dec 2016 08:12:34 +0000 >> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: >> >>> On 08/12/2016 03:49, hughaguilar96@gmail.com wrote: >>>> Other languages use some kind of prefix or suffix to indicate >>>> hexadecimal --- we have $ in Pascal and 0x in C. >>> >>> Forth 2012/20XX has prefixes: >>> >>> # for decimal numbers >>> $ for hex >>> % for binary >>> >>> See section 3.4.1.3 in http://forth-standard.org/standard/usage >>> >> >> Why are # $ % number prefixes instead of standalone Forth words? I.e., >> why aren't they followed by a space? The parsing would seem to be more >> C style than Forth. >> >> >> Rod Pemberton >> >Because either # 123 has # parse 123, or it changes the current base >without being able to restore it, and is equivalent to DECIMAL 123. >Neither is desirable. (And # is already a word.) Bad answer, because it would be sufficient to rename # to hash. They are a prefix, because $1234 is one thing, a number. To be distracted by having to think: we have a $ here .. it parse .. ot gets a number .. now am I compiling .. yes so I compile a lit then a that number .. is just plain bad. The same applies to ' but there everybody except me seems to be willing to put up with the above. (And because the concept that there should be one handle to identify a Forth word doesn't seem to gain acceptance.) > >-- >Alex -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-09 13:01 +0000 |
| Message-ID | <2016Dec9.140124@mips.complang.tuwien.ac.at> |
| In reply to | #53221 |
albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>The same applies to ' but there everybody except me seems to be willing
>to put up with the above.
You could make a proposal for a prefix to replace ' and ['], and see
how it flies. However, I fear that you would put in so much
idiosyncratic stuff that your proposal would not fly. But my guess is
that allowing to write, say "`abc", instead of "' abc" and "['] abc"
would be quite popular among Forth programmers, because it would allow
copy-paste between interpretive and compiled code.
>(And because the concept that there should be one handle to identify
>a Forth word doesn't seem to gain acceptance.)
You can find agreement from Stephen Pelc on that, but AFAIK you think
that this handle should be what you call a DEA, and he thinks that the
handle should be "the xt".
And when you look at the current discussion about SYNONYM
<http://forth-standard.org/standard/tools/SYNONYM>, the details are
tricky:
If you have
SYNONYM NEW OLD
Should NEW have the same handle as OLD? Should it have the same nt?
Should "FIND-NAME NEW NAME>STRING TYPE" print "NEW" or "OLD"? IMO it
should print "NEW".
Should "FIND-NAME NEW NAME>INTERPRET" return the same xt as
"FIND-NAME OLD NAME>INTERPRET"? Not necessarily, but returning the
same xt would naturally allow applying >BODY, DEFER@ and DEFER! if OLD
is a word where that is allowed.
Similarly for NAME>COMPILE.
- 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-09 11:19 +1100 |
| Message-ID | <o2ct9g$aaa$1@gioia.aioe.org> |
| In reply to | #53208 |
Rod Pemberton wrote: > On Thu, 8 Dec 2016 08:12:34 +0000 > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > > > On 08/12/2016 03:49, hughaguilar96@gmail.com wrote: > > > Other languages use some kind of prefix or suffix to indicate > > > hexadecimal --- we have $ in Pascal and 0x in C. > > > > Forth 2012/20XX has prefixes: > > > > # for decimal numbers > > $ for hex > > % for binary > > > > See section 3.4.1.3 in http://forth-standard.org/standard/usage > > > > Why are # $ % number prefixes instead of standalone Forth words? I.e., > why aren't they followed by a space? The parsing would seem to be more > C style than Forth. > > > Rod Pemberton That's correct but the former is common notation for numbers in the rest of the computing world. In the past Forth *has* used explicit words H# D# F# etc to denote hex/ decimal/float numbers respectively. The beauty of these is that - unlike the former - you don't need to hack your interpreter to provide them!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-08 22:23 -0800 |
| Message-ID | <9bb564ba-a0b6-47ec-9da4-7ee1755c9922@googlegroups.com> |
| In reply to | #53212 |
On Thursday, December 8, 2016 at 5:19:04 PM UTC-7, HAA wrote: > Rod Pemberton wrote: > > On Thu, 8 Dec 2016 08:12:34 +0000 > > Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote: > > > > > On 08/12/2016 03:49, hughaguilar96@gmail.com wrote: > > > > Other languages use some kind of prefix or suffix to indicate > > > > hexadecimal --- we have $ in Pascal and 0x in C. > > > > > > Forth 2012/20XX has prefixes: > > > > > > # for decimal numbers > > > $ for hex > > > % for binary > > > > > > See section 3.4.1.3 in http://forth-standard.org/standard/usage > > > > > > > Why are # $ % number prefixes instead of standalone Forth words? I.e., > > why aren't they followed by a space? The parsing would seem to be more > > C style than Forth. > > > > > > Rod Pemberton > > That's correct but the former is common notation for numbers in the rest > of the computing world. In Straight Forth I won't have recognizers --- that is pointless complication. I will have a few common conveniences such as $ and % for hexadecimal and binary numbers --- these improve the readability of the source-code a lot. > In the past Forth *has* used explicit words H# D# F# etc to denote hex/ > decimal/float numbers respectively. The beauty of these is that - unlike > the former - you don't need to hack your interpreter to provide them! Something like this is still necessary in cross-compilers because ANS-Forth failed to make LITERAL vectored so it is not possible to have literal numbers in target code unless you explicitely use LITERAL yourself (then you use your own LITERAL rather than the built-in LITERAL that is used by the outer-interpreter). Nothing was vectored in ANS-Forth --- the "Starting Forth" book described vectored execution as a "hairy" subject --- apparently nobody on the ANS-Forth committee understood this hairy subject, which is why they didn't make words vectored that needed to be vectored. ANS-Forth is confusing! I was testing my words under VFX just now and came to this: 12345.6789e engineering ok-2 type 12.345679e32 ok WTF??? Does my code have a bug??? Then I tried this: 12345.6789e engineering type 12.345679e3 ok This works. I realized then that the problem was not in my code, it was in ANS-Forth --- the outer-interpreter uses the same memory location for multiple purposes --- my <SCIENTIFIC> is using the buffer that <# #> uses, and this buffer gets clobbered by the outer-interpreter before the TYPE gets done on the next line. So, despite the fact that I've been programming in Forth since 1984, I can still get confused by ANS-Forth. I did figure out what was happening in a matter of seconds, but I was quite confused during those seconds when I didn't know what was happening. Forth students are not going to figure this out in a matter of seconds, or even in a matter of minutes --- they are going to be pretty baffled as to why the code works sometimes and doesn't work other times --- hours later, still confused, they are going to give up on Forth and switch to another language without all this confusion regarding basic concepts such as printing out numbers. Of course, the ANS-Forth enthusiasts will say that I'm an "idiot" because I was confused by the weird output of 12.345679e32 even for a few seconds --- ANS-Forth is a cult --- their world-view demands that Forth programmers who find fault with ANS-Forth must be utterly incompetent and total idiots, but that is unrealistic because most people aren't total idiots but are at least somewhat intelligent (maybe even intelligent enough to print out a number). All of these ANS-Forth cult members on comp.lang.forth enjoy telling me that I'm utterly incompetent and a total idiot --- they think they are really beating me into submission --- this just weirds me out; I know that I'm not an idiot; they are not going to convince me that I am. In Straight Forth I am going to get rid of all this confusing nonsense. My <SCIENTIFIC> used above should work in any context. It should be easy to make the system work in a consistent way. ANS-Forth was based on a Forth that Charles Moore wrote for the PDP-11 in the 1970s --- C.M. was reusing the same memory for multiple purposes because 1970s computers had an extreme shortage of RAM. Reusing memory for multiple purposes, and having unrelated aspects of the language clobber each other's data, is very bad design --- this hasn't been done since the 1970s --- it is a bug by modern-day standards.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 07:11 -0800 |
| Message-ID | <f081edc9-23ec-4d29-bb4b-47ce6b4f9834@googlegroups.com> |
| In reply to | #53215 |
On Thursday, December 8, 2016 at 11:23:05 PM UTC-7, hughag...@gmail.com wrote: > ANS-Forth is confusing! I was testing my words under VFX just now and came to this: > > 12345.6789e engineering ok-2 > type 12.345679e32 ok > > WTF??? Does my code have a bug??? Then I tried this: > > 12345.6789e engineering type 12.345679e3 ok > > This works. I realized then that the problem was not in my code, it was in ANS-Forth --- the outer-interpreter uses the same memory location for multiple purposes --- my <SCIENTIFIC> is using the buffer that <# #> uses, and this buffer gets clobbered by the outer-interpreter before the TYPE gets done on the next line. > ... > In Straight Forth I am going to get rid of all this confusing nonsense. My <SCIENTIFIC> used above should work in any context. It should be easy to make the system work in a consistent way. Straight Forth has a string-stack (the same as STRING-STACK.4TH that I wrote in ANS-Forth). It doesn't have TYPE so the above problem would never occur. All strings are worked with on the string-stack and it is very rare to remove a string from the string-stack. In Straight Forth, <# #> would push a string onto the string-stack --- to print it out, .$ would be used. You can push multiple strings onto the string-stack (it is a stack, you know), and they don't over-write each other. It is utterly retarded that ANS-Forth uses one memory block for all of its strings, so if you have more than one string the latest string over-writes the previous strings. That is stupid! Even line-number BASIC on the old 8-bit computers of the 1980s had better string-handling than that! I can easily imagine an ANS-Forth student running into a problem like this: 12345.6789e engineering ok-2 type 12.345679e32 ok Then the student asks on comp.lang.forth what is wrong. He gets these responses: John Passaniti: "You suck!" Elizabeth Rather: "You're homophobic!" Bernd Paysan: "You're stupid!" Alex McDonald: "You have a serious misunderstanding of how pointers work!" Stephen Pelc: "RTFM!" Andrew Haley: "You're jealous of me!" This might be why nobody is volunteering to be an ANS-Forth student, do you think? Actually, what the student will think is that there is a bug in my novice-package --- he will abandon the novice-package --- he will become a typical ANS-Forth programmer who spends all of his time on comp.lang.forth posting code copied directly out of the "Starting Forth" book and flinging insults at me.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-20 22:40 -0800 |
| Message-ID | <6b1ce19e-c16c-49cd-90d9-3d322ba21376@googlegroups.com> |
| In reply to | #53227 |
On Friday, December 9, 2016 at 8:11:08 AM UTC-7, hughag...@gmail.com wrote: > On Thursday, December 8, 2016 at 11:23:05 PM UTC-7, hughag...@gmail.com wrote: > > ANS-Forth is confusing! I was testing my words under VFX just now and came to this: > > > > 12345.6789e engineering ok-2 > > type 12.345679e32 ok > > > > WTF??? Does my code have a bug??? Then I tried this: > > > > 12345.6789e engineering type 12.345679e3 ok > > > > This works. I realized then that the problem was not in my code, it was in ANS-Forth --- the outer-interpreter uses the same memory location for multiple purposes --- my <SCIENTIFIC> is using the buffer that <# #> uses, and this buffer gets clobbered by the outer-interpreter before the TYPE gets done on the next line. > > ... > > In Straight Forth I am going to get rid of all this confusing nonsense. My <SCIENTIFIC> used above should work in any context. It should be easy to make the system work in a consistent way. > > Straight Forth has a string-stack (the same as STRING-STACK.4TH that I wrote in ANS-Forth). It doesn't have TYPE so the above problem would never occur. All strings are worked with on the string-stack and it is very rare to remove a string from the string-stack. In Straight Forth, <# #> would push a string onto the string-stack --- to print it out, .$ would be used. You can push multiple strings onto the string-stack (it is a stack, you know), and they don't over-write each other. > > It is utterly retarded that ANS-Forth uses one memory block for all of its strings, so if you have more than one string the latest string over-writes the previous strings. That is stupid! Even line-number BASIC on the old 8-bit computers of the 1980s had better string-handling than that! > > I can easily imagine an ANS-Forth student running into a problem like this: > > 12345.6789e engineering ok-2 > type 12.345679e32 ok > > Then the student asks on comp.lang.forth what is wrong. He gets these responses: > > John Passaniti: "You suck!" > Elizabeth Rather: "You're homophobic!" > Bernd Paysan: "You're stupid!" > Alex McDonald: "You have a serious misunderstanding of how pointers work!" > Stephen Pelc: "RTFM!" > Andrew Haley: "You're jealous of me!" > > This might be why nobody is volunteering to be an ANS-Forth student, do you think? > > Actually, what the student will think is that there is a bug in my novice-package --- he will abandon the novice-package --- he will become a typical ANS-Forth programmer who spends all of his time on comp.lang.forth posting code copied directly out of the "Starting Forth" book and flinging insults at me. As for Gerry who thinks I'm procrastinating on Straight Forth, let me point out that I spent several days writing STRING-STACK.4TH --- you checked it for me and found some bugs, which I fixed --- STRING-STACK.4TH will be in the next novice-package release in a few days. Why didn't ANS-Forth have a string-stack? As I recall, a string-stack was discussed in "Forth Dimensions" in the late 1980s. The concept was known. ANS-Forth was just the corpse of Charles Moore's old Forth system from the 1970s warmed over --- ANS-Forth was lacking a lot of important features --- the business of using the same memory block for multiple strings and multiple purposes, is horrible design, even by 1970s standards, and certainly by 1980s standards. I think my string-stack works quite well because it does that COW (copy on write) business, which reduces the number of calls to ALLOCATE and FREE, which are typically speed killers. I didn't know the term COW when I wrote my string-stack, but afaik it is the correct term for what I'm doing. ANS-Forth came out in 1994 without a string-stack. Now it is 2016 and Forth-200x lacks a string-stack also. We still have problems such as shown above in which a string gets clobbered when the user expects it to still be valid. Why don't we have a string-stack yet? Has the Forth-200x committee been too busy sorting screws in the garage? It has been over 30 years since the idea of a string-stack was first introduced --- they must have collected buckets of screws by now. Anyway, Straight Forth will definitely have the string-stack --- all strings will be on the string-stack. There won't be TYPE that accesses a string somewhere. There will only be .$ that types the top value of the string-stack and drops it from the string-stack (first upgrading any derivatives to uniques of the string being dropped is a unique). This is a good design! This should have been done decades ago! So, get off my case about taking too long with Straight Forth --- I'm not in a hurry because everybody on comp.lang.forth will just say that it is "crap" when I do release it --- if you have any interest in Straight Forth other than to call it "crap," then why don't you help with it? Why are you wasting your time with Forth-200x? The Forth-200x Standard is destined to be completely ignored in the real world, just like the ANS-Forth Standard has been completely ignored in the real world for over two decades. I can't guarantee that Straight Forth will be noticed in the real world, but it has a lot better chance than Forth-200x --- it is a modern language with features expected in the 21st century.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-12-20 23:59 -0800 |
| Message-ID | <9afcee4c-2f94-4cc0-88de-2c66de09398a@googlegroups.com> |
| In reply to | #53461 |
On Wednesday, December 21, 2016 at 12:41:00 AM UTC-6, hughag...@gmail.com wrote: > > Why didn't ANS-Forth have a string-stack? As I recall, a string-stack was discussed in "Forth Dimensions" in the late 1980s. The concept was known. ANS-Forth was just the corpse of Charles Moore's old Forth system from the 1970s warmed over --- ANS-Forth was lacking a lot of important features --- the business of using the same memory block for multiple strings and multiple purposes, is horrible design, even by 1970s standards, and certainly by 1980s standards. > Forth Dimensions had lots of articles with lots of concepts. This one has come up a few times. You think it's so essential that only fools wouldn't include it in the standard. I think it's weird and dumb, probably the result of someone starting from "this is Forth, so a stack should be central somehow" rather than from some needs of some application. The difference between your opinion and mine is that I'm aware that mine isn't also universal truth, but you think that everyone who looks upon your string stack must be awed. > all strings will be on the string-stack. There won't be TYPE that accesses a string somewhere. There will only be .$ that types the top value of the string-stack and drops it from the string-stack (first upgrading any derivatives to uniques of the string being dropped is a unique). This is a good design! This should have been done decades ago! "Wow! I can't even say 'hello' without using dynamically allocated memory!" ^-- a very likely statement from someone interested in Forth. Honestly, Hugh, you're just too smart and advanced for Forth. You should be really playing with the Haskell kids. Stop worrying about the opinions of your inferiors. All that holds you back from Haskell are the scars of completely undeserved criticism--people saying that your code 'sucks' when obviously none of them has ever written any Forth that wasn't cribbed from Leo Brodie! That's even why I don't like string stacks: Starting Forth didn't cover them. You may have some prejudices about Haskell, but I guarantee you that you'll find them to be illusory. Haskell is actually much more efficient than Forth. For example, when was the last time you heard someone in comp.lang.forth talk about 'deforestation'? Passanti would probably say that deforestation 'sucks' because it harming the environment, ha ha ha. In fact it's a optimization technique available to advanced Haskell compilers -- compilers of 2016, not of the 1990s or 1980s -- that permits them to avoid ever creating short-lived intermediate data structures in the first place. Think about that: with Haskell, you could have some code that pushes a string to your string-stack and then prints it, and the compiled program might transparently skip the unnecessary steps. Forth just can't do that. Still, I'm sure there will be some need for a Straight Haskell of sorts, but here too you'll find that the Haskell community is more receptive to new and disruptive ideas. They already did some 'lens' thing that I'm just too much of a backwards Forther to care about, but I think it involved replacing barely comprehensible types with completely incomprehensible types, with the benefit that the incomprehensible types lend themselves to prettier code. There are also no shills or corporate employees trying to conquer the Haskell community for themselves. It's just a bunch of egoless academics, motivated by pure curiousity and the spirit of progress. These saints would never say that you aren't a 'real' Haskell programmer. Please consider it. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-21 21:17 -0800 |
| Message-ID | <25e73acc-fd4a-4b54-a39a-0a226f32898f@googlegroups.com> |
| In reply to | #53461 |
On Tuesday, December 20, 2016 at 11:41:00 PM UTC-7, hughag...@gmail.com wrote: > ANS-Forth came out in 1994 without a string-stack. Now it is 2016 and Forth-200x lacks a string-stack also. We still have problems such as shown above in which a string gets clobbered when the user expects it to still be valid. Why don't we have a string-stack yet? Has the Forth-200x committee been too busy sorting screws in the garage? It has been over 30 years since the idea of a string-stack was first introduced --- they must have collected buckets of screws by now. > > Anyway, Straight Forth will definitely have the string-stack --- all strings will be on the string-stack. There won't be TYPE that accesses a string somewhere. There will only be .$ that types the top value of the string-stack and drops it from the string-stack (first upgrading any derivatives to uniques of the string being dropped is a unique). This is a good design! This should have been done decades ago! <# will create a unique string and push it on to the string-stack. It can be made pretty big to start with, and then #> can trim off the unused portion to save memory. It would be possible to do a <# ... #> inside of another <# ... #> because they don't use the same string. In the ANS-Forth document (3.3.3.6) we have the section: "Other transient regions" Here is the whole section: ---------------------------------------------------------------------------------- The data space regions identified by PAD, WORD, and #> (the pictured numeric output string buffer) may be transient. Their addresses and contents may become invalid after: – a definition is created via a defining word; – definitions are compiled with : or :NONAME; – data space is allocated using ALLOT, , (comma), C, (c-comma), or ALIGN. The previous contents of the regions identified by WORD and #> may be invalid after each use of these words. Further, the regions returned by WORD and #> may overlap in memory. Consequently, use of one of these words can corrupt a region returned earlier by a different word. The other words that construct pictured numeric output strings (<#, #, #S, and HOLD) may also modify the contents of these regions. Words that display numbers may be implemented using pictured numeric output words. Consequently, . (dot), .R, .S, ?, D., D.R, U., and U.R could also corrupt the regions. The size of the scratch area whose address is returned by PAD shall be at least 84 characters. The contents of the region addressed by PAD are intended to be under the complete control of the user: no words defined in this Standard place anything in the region, although changing data-space allocations as described in 3.3.3.2 Contiguous regions may change the address returned by PAD. Non-standard words provided by an implementation may use PAD, but such use shall be documented. The size of the region identified by WORD shall be at least 33 characters. The size of the pictured numeric output string buffer shall be at least (2*n) + 2 characters, where n is the number of bits in a cell. Programs that consider it a fixed area with unchanging access parameters have an environmental dependency. ---------------------------------------------------------------------------------- This is utterly stupid! ANS-Forth is documenting how the various unrelated words can corrupt each other's data!
[toc] | [prev] | [next] | [standalone]
| From | The Beez <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2016-12-13 08:51 -0800 |
| Message-ID | <652b6441-c601-4868-88cd-0a8d9518272a@googlegroups.com> |
| In reply to | #53215 |
On Friday, December 9, 2016 at 7:23:05 AM UTC+1, hughag...@gmail.com wrote: > 12345.6789e engineering ok-2 > type 12.345679e32 ok > > WTF??? Does my code have a bug??? Then I tried this: > > 12345.6789e engineering type 12.345679e3 ok > > This works. I realized then that the problem was not in my code, it was in ANS-Forth --- the outer-interpreter uses the same memory location for multiple purposes --- my <SCIENTIFIC> is using the buffer that <# #> uses, and this buffer gets clobbered by the outer-interpreter before the TYPE gets done on the next line. Something similar happened to me too while I was debugging a program using the picture buffer with .S Baffled me for a while before I figured out what was going on ;-) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-09 12:47 +0000 |
| Message-ID | <2016Dec9.134735@mips.complang.tuwien.ac.at> |
| In reply to | #53212 |
"HAA" <someone@microsoft.com> writes:
>Rod Pemberton wrote:
>> On Thu, 8 Dec 2016 08:12:34 +0000
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>> > Forth 2012/20XX has prefixes:
>> >
>> > # for decimal numbers
>> > $ for hex
>> > % for binary
>> >
>> > See section 3.4.1.3 in http://forth-standard.org/standard/usage
>> >
>>
>> Why are # $ % number prefixes instead of standalone Forth words? I.e.,
>> why aren't they followed by a space?
1) $ff is common practice, $ ff isn't.
2) S" sucks, and so would these words.
>In the past Forth *has* used explicit words H# D# F# etc to denote hex/
>decimal/float numbers respectively. The beauty of these is that - unlike
>the former - you don't need to hack your interpreter to provide them!
When we standardize recognizers, you don't need to write
system-specific code (aka "hack your interpreter") to add such syntax,
either, so the "beauty" of H# just points to a deficiency in the
standard. Open Firmware has H#, but neither Gforth, nor SwiftForth,
nor VFX have it; in Open Firmware it's a STATE-smart word, with all
the problems this implies.
- 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 | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-10 11:54 +1100 |
| Message-ID | <o2fjmu$9cq$1@gioia.aioe.org> |
| In reply to | #53224 |
Anton Ertl wrote: > "HAA" <someone@microsoft.com> writes: > ... > >In the past Forth *has* used explicit words H# D# F# etc to denote hex/ > >decimal/float numbers respectively. The beauty of these is that - unlike > >the former - you don't need to hack your interpreter to provide them! > > When we standardize recognizers, you don't need to write > system-specific code (aka "hack your interpreter") to add such syntax, > either, so the "beauty" of H# just points to a deficiency in the > standard. How is having less complicated compiler a "deficiency" ? We are talking about Forth are we not. > Open Firmware has H#, but neither Gforth, nor SwiftForth, > nor VFX have it; The majority opted for convention which 200x endorsed along with the not-so-conventional way of dealing with negative numbers. It doesn't mean H# was bad. It's just that the majority won. > in Open Firmware it's a STATE-smart word, with all > the problems this implies. Forth was never intended for dummies. The Forth-83 stance on state-smartness has been regarded by some as over-reaction. I have several state-smart words in the kernel. If I've ever been bitten by them I no longer recall it. Perhaps state-smartness is not the evil lurking monster it has been painted. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 17:28 -0800 |
| Message-ID | <3aa1d833-6b5c-4c8e-b9fe-f1cad0002502@googlegroups.com> |
| In reply to | #53241 |
On Friday, December 9, 2016 at 5:53:54 PM UTC-7, HAA wrote:
> Forth was never intended for dummies. The Forth-83 stance on
> state-smartness has been regarded by some as over-reaction.
> I have several state-smart words in the kernel. If I've ever been
> bitten by them I no longer recall it. Perhaps state-smartness is
> not the evil lurking monster it has been painted.
I have quite a lot of words in the novice-package that are immediate --- all of my MACRO: words are immediate.
I've never been bitten by this. All of these words are low-level words that nobody is going to tick --- state-smartness should not be used with high-level words that sombody might tick and then expect to execute the xt at run-time as if it were a regular colon word.
For example:
macro: rover ( a b c -- a b c a )
2 pick ;
Realistically, nobody is going to tick this.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 18:20 -0800 |
| Message-ID | <1b10af7b-6517-4ae3-ac33-37086f1961aa@googlegroups.com> |
| In reply to | #53241 |
On Friday, December 9, 2016 at 5:53:54 PM UTC-7, HAA wrote: > Anton Ertl wrote: > > in Open Firmware H# is a STATE-smart word, with all > > the problems this implies. > > Forth was never intended for dummies. The Forth-83 stance on > state-smartness has been regarded by some as over-reaction. > I have several state-smart words in the kernel. If I've ever been > bitten by them I no longer recall it. Perhaps state-smartness is > not the evil lurking monster it has been painted. Nobody is going to tick H# so no problems are implied. I'm not going to have H# in Straight Forth though --- hexadecimal and binary numbers are so common that it is worthwhile to upgrade the outer-interpreter to support $ and % for them (this will be documented) --- if somebody wants octal numbers for some obscure reason though, then they will have to write a state-smart X# for that (I've never seen octal numbers used in practice; they may have been used in the mainframe world at one time). I think recognizers are a horrible idea --- that is just pointless complication --- that is completely contrary to the name "Straight Forth" which implies a straight-forward design.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-12-10 14:26 +0000 |
| Message-ID | <2016Dec10.152628@mips.complang.tuwien.ac.at> |
| In reply to | #53241 |
"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>> ...
>> >In the past Forth *has* used explicit words H# D# F# etc to denote hex/
>> >decimal/float numbers respectively. The beauty of these is that - unlike
>> >the former - you don't need to hack your interpreter to provide them!
>>
>> When we standardize recognizers, you don't need to write
>> system-specific code (aka "hack your interpreter") to add such syntax,
>> either, so the "beauty" of H# just points to a deficiency in the
>> standard.
>
>How is having less complicated compiler a "deficiency" ?
You pointed out the deficiency: The need to use system-specific code
(or, in your words, to "hack your interpreter") in order to provide
number prefixes.
Concerning "less complicated compiler", where is your proof of that?
Systems have provided floating-point literals, number prefixes,
support for other double indicators, dot-parsers etc. through
system-specific means, which may well be more complicated than one
general recognizer mechanism.
Look at another example, where we already have a general mechanism:
dictionary words. Instead of that, we could hard-code all the
predefined Forth words in the text interpreter (like we do with the
number parser in Forth); would the text interpreter become simpler?
For adding new words, we could add a bunch of system-specific hooks;
or we could have a parsing state-smart word (say W) that parses the
user-defined word and does a lookup and interpretation/compilation,
avoiding the complexity of the hooks; or we could have the general
mechanism that we have now. Which one is better?
>> in Open Firmware it's a STATE-smart word, with all
>> the problems this implies.
>
>Forth was never intended for dummies.
Do you suggest to design complicated interfaces, that don't work as
expected under some circumstances, and when a user falls into the
trap, defend the interface by calling the user a dummy? Yes, the
reaction appeals to the elitist reflexes in programmers, but that
still does not make such interfaces a good idea.
>The Forth-83 stance on
>state-smartness has been regarded by some as over-reaction.
Sure, there are STATE-smartness apologists around; that does not mean
that we should go for STATE-smartness when we know a better
alternative. The Forth-83 way of having two parsing words (e.g., '
and [']) does not have the hidden traps of STATE-smartness, but it has
the obvious disadvantage of not allowing to cut and paste between
interpretation and compilation state. Fortunately, in the meantime we
have a solution that has neither the disadvantages of STATE-smartness
(nor of the Forth-94 arbitrary combinations of interpretation and
compilation semantics), nor that of the Forth-83 '/['] solution: Avoid
parsing words by using recognizers.
>I have several state-smart words in the kernel. If I've ever been
>bitten by them I no longer recall it.
The fact that programmers tend not to notice the problems that their
code has is well known, especially in user-interface design and in
program testing.
- 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 | The Beez <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2016-12-13 09:14 -0800 |
| Message-ID | <2ade5911-a790-4ec7-b1da-6ea478225f09@googlegroups.com> |
| In reply to | #53262 |
On Saturday, December 10, 2016 at 5:44:49 PM UTC+1, Anton Ertl wrote: > >> >In the past Forth *has* used explicit words H# D# F# etc to denote hex/ > >> >decimal/float numbers respectively. The beauty of these is that - unlike > >> >the former - you don't need to hack your interpreter to provide them! > You pointed out the deficiency: The need to use system-specific code > (or, in your words, to "hack your interpreter") in order to provide > number prefixes. > > Concerning "less complicated compiler", where is your proof of that? > Systems have provided floating-point literals, number prefixes, > support for other double indicators, dot-parsers etc. through > system-specific means, which may well be more complicated than one > general recognizer mechanism. > Sure, there are STATE-smartness apologists around; that does not mean > that we should go for STATE-smartness when we know a better > alternative. The Forth-83 way of having two parsing words (e.g., ' > and [']) does not have the hidden traps of STATE-smartness, but it has > the obvious disadvantage of not allowing to cut and paste between > interpretation and compilation state. Fortunately, in the meantime we > have a solution that has neither the disadvantages of STATE-smartness > (nor of the Forth-94 arbitrary combinations of interpretation and > compilation semantics), nor that of the Forth-83 '/['] solution: Avoid > parsing words by using recognizers. > > >I have several state-smart words in the kernel. If I've ever been > >bitten by them I no longer recall it. > > The fact that programmers tend not to notice the problems that their > code has is well known, especially in user-interface design and in > program testing. Well, not having an interpreter in 4tH really simplifies things ;-) According to your definition either EVERY word is smart or none. If you try to tick a word that isn't tickable, the compiler simply says so - it won't allow it. But "hacking your interpreter" is NOT every elegant either. Chuck Moore HATED hooks: "Don't anticipate" was his motto. I still think H# is much more Forth-like - regardless whether it is "state-smart" or not. S" is state smart, I haven't seen a S( yet. State smart has its use. I don't think it should be tickable though.. Much like immediate words. You quickly get lost. The next best alternative is S" mynumber" >MYNUMBER, but that ALWAYS carries runtime overhead. That's the 4tH way to handle things. Any H# like words are converted to this form using the preprocessor. Point is, Forth is Forth and you can't have your cake and eat it too. The sorry state of any current Forth standard reflects this. Because in the end, if you hate state smart words so much, why don't you simply and completely outlaw them? Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2016-12-13 19:24 +0100 |
| Message-ID | <o2pecm$jba$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #53313 |
In article <2ade5911-a790-4ec7-b1da-6ea478225f09@googlegroups.com>, The Beez <the.beez.speaks@gmail.com> wrote: >On Saturday, December 10, 2016 at 5:44:49 PM UTC+1, Anton Ertl wrote: >> >> >In the past Forth *has* used explicit words H# D# F# etc to denote h= >ex/ >> >> >decimal/float numbers respectively. The beauty of these is that - un= >like >> >> >the former - you don't need to hack your interpreter to provide them! > >> You pointed out the deficiency: The need to use system-specific code >> (or, in your words, to "hack your interpreter") in order to provide >> number prefixes. >>=20 >> Concerning "less complicated compiler", where is your proof of that? >> Systems have provided floating-point literals, number prefixes, >> support for other double indicators, dot-parsers etc. through >> system-specific means, which may well be more complicated than one >> general recognizer mechanism. >=20 >> Sure, there are STATE-smartness apologists around; that does not mean >> that we should go for STATE-smartness when we know a better >> alternative. The Forth-83 way of having two parsing words (e.g., ' >> and [']) does not have the hidden traps of STATE-smartness, but it has >> the obvious disadvantage of not allowing to cut and paste between >> interpretation and compilation state. Fortunately, in the meantime we >> have a solution that has neither the disadvantages of STATE-smartness >> (nor of the Forth-94 arbitrary combinations of interpretation and >> compilation semantics), nor that of the Forth-83 '/['] solution: Avoid >> parsing words by using recognizers. >>=20 >> >I have several state-smart words in the kernel. If I've ever been >> >bitten by them I no longer recall it. >>=20 >> The fact that programmers tend not to notice the problems that their >> code has is well known, especially in user-interface design and in >> program testing. >Well, not having an interpreter in 4tH really simplifies things ;-) Accordi= >ng to your definition either EVERY word is smart or none. If you try to tic= >k a word that isn't tickable, the compiler simply says so - it won't allow = >it. > >But "hacking your interpreter" is NOT every elegant either. Chuck Moore HAT= >ED hooks: "Don't anticipate" was his motto. I still think H# is much more F= >orth-like - regardless whether it is "state-smart" or not. S" is state smar= >t, I haven't seen a S( yet. State smart has its use. I don't think it shoul= >d be tickable though.. Much like immediate words. You quickly get lost. The anticipation words have no use except for what other languages call literals (and I had to name denotations in Forth.) Those words are by nature statesmart, like numbers always were. If you want them to look natural they can be implemented by adding one word (PREFIX). Don't even think of postponing literals of any kind. You mess up your brain and that of others. > >Hans Bezemer -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-14 07:29 -0600 |
| Message-ID | <Sqidnav_0evY1MzFnZ2dnUU7-eXNnZ2d@supernews.com> |
| In reply to | #53313 |
The Beez <the.beez.speaks@gmail.com> wrote: > > Point is, Forth is Forth and you can't have your cake and eat it > too. The sorry state of any current Forth standard reflects > this. Because in the end, if you hate state smart words so much, why > don't you simply and completely outlaw them? That one is easy: no common practice, don't break code. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2016-12-14 18:29 +0100 |
| Message-ID | <585181ad$0$21509$e4fe514c@news.xs4all.nl> |
| In reply to | #53320 |
Andrew Haley wrote: >> Point is, Forth is Forth and you can't have your cake and eat it >> too. The sorry state of any current Forth standard reflects >> this. Because in the end, if you hate state smart words so much, why >> don't you simply and completely outlaw them? > That one is easy: no common practice, don't break code. Pragmatism rarely leads to good design. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web