Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #58497 > unrolled thread
| Started by | Alex <alex@rivadpm.com> |
|---|---|
| First post | 2017-05-02 15:27 +0100 |
| Last post | 2017-05-04 10:07 -0700 |
| Articles | 20 on this page of 177 — 26 participants |
Back to article view | Back to comp.lang.forth
Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 15:27 +0100
Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 07:52 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-02 08:19 -0700
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-02 08:27 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:55 +0100
Re: Recognizers discussion lehs <skydda.barnen@gmail.com> - 2017-05-03 02:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 15:16 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:05 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:23 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 17:26 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:03 -0500
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-02 12:44 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:36 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:28 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:13 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 12:35 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 18:53 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-02 13:10 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-02 19:22 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-02 22:53 +0000
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-03 07:39 +0100
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 10:58 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 13:53 +0000
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-06 01:21 +0000
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 00:22 -0700
Re: Recognizers discussion Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-05-06 23:05 +0100
Re: Recognizers discussion pahihu <pahihu@gmail.com> - 2017-05-06 22:36 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 04:38 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 04:49 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 05:03 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 09:02 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 07:45 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:24 -0500
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:45 -0700
Re: Recognizers discussion Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-03 10:08 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:56 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:37 +0100
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 11:07 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 20:55 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:47 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:07 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 07:59 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:38 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 12:42 -0500
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:43 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:05 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:10 +0300
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:25 +0100
Re: Recognizers discussion Ron Aaron <rambamist@gmail.com> - 2017-05-04 15:33 +0300
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 08:05 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 15:54 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 11:10 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:49 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-04 16:14 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 13:02 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-05 23:29 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:56 -0500
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 22:42 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:08 -0500
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 08:51 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 09:38 -0700
Re: Recognizers discussion Julian Fondren <julian.fondren@gmail.com> - 2017-05-03 09:59 -0700
Re: Recognizers discussion Mark Wills <markwills1970@gmail.com> - 2017-05-03 10:16 -0700
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 22:04 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 22:09 -0700
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-07 19:50 -0700
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-07 21:33 -1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-08 04:12 -0500
Re: Recognizers discussion Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:21 -0700
FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 12:35 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-08 20:50 -0700
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-09 03:39 -0500
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-09 20:59 -0700
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:03 -0700
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:10 +0100
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:24 -1000
Re: FP stack Julian Fondren <julian.fondren@gmail.com> - 2017-05-10 00:37 -0700
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 22:53 -1000
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 08:53 +0100
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:00 +0300
Re: FP stack Paul Rubin <no.email@nospam.invalid> - 2017-05-10 01:02 -0700
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 11:06 +0300
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:58 +0000
Re: FP stack Ron Aaron <rambamist@gmail.com> - 2017-05-10 14:17 +0300
Re: FP stack Alex <alex@rivadpm.com> - 2017-05-10 13:09 +0100
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 15:05 +0000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 11:43 +0200
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-10 18:34 +1000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 09:45 +0000
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-11 19:13 +1000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 04:50 -0500
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:18 +0000
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-11 12:12 -0500
Re: FP stack stephen@mpeforth.com (Stephen Pelc) - 2017-05-11 13:53 +0000
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 15:43 +0000
Re: FP stack Joel Rees <joel.rees@gmail.com> - 2017-05-12 08:48 -0700
Re: FP stack anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-11 16:31 +0000
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 10:18 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 15:37 -0500
Re: FP stack "Elizabeth D. Rather" <erather@forth.com> - 2017-05-11 17:25 -1000
Re: FP stack Cecil Bayona <cbayona@cbayona.com> - 2017-05-11 22:55 -0500
Re: FP stack "HAA" <someone@microsoft.com> - 2017-05-13 14:24 +1000
Re: FP stack albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-13 13:44 +0200
Re: FP stack Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-10 05:58 -0500
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 13:50 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 00:25 -0700
Re: FP stack (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 11:39 +0000
Re: FP stack (was: Recognizers discussion) Joel Rees <joel.rees@gmail.com> - 2017-05-10 11:49 -0700
Re: FP stack (was: Recognizers discussion) "HAA" <someone@microsoft.com> - 2017-05-09 21:15 +1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-09 14:16 +1000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 08:57 -0500
Re: Recognizers discussion minforth@arcor.de - 2017-05-03 07:54 -0700
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-03 11:30 -0500
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-03 14:05 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-03 18:42 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 02:51 -0500
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-04 22:29 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 13:41 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-04 09:06 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-15 12:22 +0000
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-15 07:36 -0500
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:21 +0000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-18 21:24 +0000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-04 20:17 +0200
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-05 11:03 +1000
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 00:16 -0700
Re: Recognizers discussion JUERGEN <epldfpga@aol.com> - 2017-05-05 13:15 -0700
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-06 16:49 +1000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-05 21:00 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-09 14:17 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-09 15:46 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 11:50 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 13:11 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-10 13:49 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-10 15:57 +0100
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-12 14:17 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-02 09:25 -1000
Re: Recognizers discussion albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-03 01:19 +0200
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-05 15:50 +0000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-08 11:43 +1000
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-08 19:17 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 14:25 +0000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-09 21:22 -1000
Re: Recognizers discussion "HAA" <someone@microsoft.com> - 2017-05-13 13:33 +1000
Re: Recognizers discussion "Elizabeth D. Rather" <erather@forth.com> - 2017-05-12 21:32 -1000
Re: Recognizers discussion Howerd <howerdo@yahoo.co.uk> - 2017-05-13 07:12 -0700
Re: Recognizers discussion "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-05-13 14:30 +0000
Re: Recognizers discussion rickman <gnuarm@gmail.com> - 2017-05-04 11:37 -0400
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-04 17:51 +0100
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-05 07:31 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-05 20:35 +0200
Re: Recognizers discussion minforth@arcor.de - 2017-05-05 12:27 -0700
Re: Recognizers discussion Cecil Bayona <cbayona@cbayona.com> - 2017-05-05 15:03 -0500
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:26 +0000
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 18:17 +0100
Re: Recognizers discussion Brad Eckert <hwfwguy@gmail.com> - 2017-05-06 12:26 -0700
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-06 21:39 +0100
Re: Recognizers discussion Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 03:58 -0500
Re: Recognizers discussion Alex <alex@rivadpm.com> - 2017-05-07 10:39 +0100
Re: Recognizers discussion Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:39 +0000
Re: Recognizers discussion Paul Rubin <no.email@nospam.invalid> - 2017-05-07 17:38 -0700
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:40 +0000
Re: Recognizers discussion anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 13:25 +0000
Re: Recognizers discussion Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-08 16:25 +0200
Flash (was: Recognizers discussion) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:51 +0000
Re: Flash Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-07 08:06 -0500
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 13:57 +0000
Re: Flash Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-07 16:46 +0200
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 16:31 +0100
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:16 +0000
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:18 +0100
Re: Flash albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 21:45 +0200
Re: Flash Matthias Trute <matthias.trute@gmail.com> - 2017-05-07 12:54 -0700
Re: Flash Alex <alex@rivadpm.com> - 2017-05-07 19:33 +0100
Re: Flash Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-07 08:50 -0700
Re: Flash anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 17:21 +0000
Re: Recognizers discussion Matthias Trute <matthias.trute@gmail.com> - 2017-05-04 10:07 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 13:07 +0100 |
| Message-ID | <oef5bt$ft7$2@dont-email.me> |
| In reply to | #58620 |
On 5/4/2017 08:47, Andrew Haley wrote: > Mark Wills <markwills1970@gmail.com> wrote: >> On Wednesday, 3 May 2017 18:37:57 UTC+1, Alex wrote: >>> There are some specific occasions when this doesn't work. How about >>> object A with method CUT and object B with method CUT. >>> >>> A CUT >>> B CUT >>> >>> How does CUT know how to find the CUT method in the object? Can we >>> efficiently compile this? We're forced into duck typing (bleuch!) and >>> the truly awful object method system that Win32Forth uses. >>> >>> People end up writing ugly hacks to get around Forth's dumb white space >>> delimited parser (a blessing in some cases, but not all). >>> >> I thought the "conventional wisdom" would be that A puts its object id >> on the stack and CUT consumes it? > > Yes, of course. This is Forth, and that's how it should work. > > Andrew. > How would this work for LINE POINT LEFT ? Who consumes what? -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 07:59 -0500 |
| Message-ID | <tridnVbb84ohuJbEnZ2dnUU7-I-dnZ2d@supernews.com> |
| In reply to | #58638 |
Alex <alex@rivadpm.com> wrote: > On 5/4/2017 08:47, Andrew Haley wrote: >> Mark Wills <markwills1970@gmail.com> wrote: >>> On Wednesday, 3 May 2017 18:37:57 UTC+1, Alex wrote: >>>> There are some specific occasions when this doesn't work. How about >>>> object A with method CUT and object B with method CUT. >>>> >>>> A CUT >>>> B CUT >>>> >>>> How does CUT know how to find the CUT method in the object? Can we >>>> efficiently compile this? We're forced into duck typing (bleuch!) and >>>> the truly awful object method system that Win32Forth uses. >>>> >>>> People end up writing ugly hacks to get around Forth's dumb white space >>>> delimited parser (a blessing in some cases, but not all). >>>> >>> I thought the "conventional wisdom" would be that A puts its object id >>> on the stack and CUT consumes it? >> >> Yes, of course. This is Forth, and that's how it should work. > > How would this work for LINE POINT LEFT ? Who consumes what? I have no idea. What are those methods supposed to do? Tell me that, and I'll tell you how it works. LINE might be an operation or just a variable name. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 17:38 +0100 |
| Message-ID | <oefl86$cuj$1@dont-email.me> |
| In reply to | #58647 |
On 5/4/2017 13:59, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> On 5/4/2017 08:47, Andrew Haley wrote: >>> Mark Wills <markwills1970@gmail.com> wrote: >>>> On Wednesday, 3 May 2017 18:37:57 UTC+1, Alex wrote: >>>>> There are some specific occasions when this doesn't work. How about >>>>> object A with method CUT and object B with method CUT. >>>>> >>>>> A CUT >>>>> B CUT >>>>> >>>>> How does CUT know how to find the CUT method in the object? Can we >>>>> efficiently compile this? We're forced into duck typing (bleuch!) and >>>>> the truly awful object method system that Win32Forth uses. >>>>> >>>>> People end up writing ugly hacks to get around Forth's dumb white space >>>>> delimited parser (a blessing in some cases, but not all). >>>>> >>>> I thought the "conventional wisdom" would be that A puts its object id >>>> on the stack and CUT consumes it? >>> >>> Yes, of course. This is Forth, and that's how it should work. >> >> How would this work for LINE POINT LEFT ? Who consumes what? > > I have no idea. What are those methods supposed to do? Tell me that, > and I'll tell you how it works. LINE might be an operation or just a > variable name. > > Andrew. > OK, poor example (as it wasn't self evident). Try this. shortLINE is an object; it contains an object called leftPOINT with a object value called X which can be set with method SET. n shortLINE leftPOINT X SET That is, object object object method. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 12:42 -0500 |
| Message-ID | <JpSdnWUouqCB9ZbEnZ2dnUU7-YnNnZ2d@supernews.com> |
| In reply to | #58672 |
Alex <alex@rivadpm.com> wrote: > On 5/4/2017 13:59, Andrew Haley wrote: >> Alex <alex@rivadpm.com> wrote: >>> How would this work for LINE POINT LEFT ? Who consumes what? >> >> I have no idea. What are those methods supposed to do? Tell me >> that, and I'll tell you how it works. LINE might be an operation >> or just a variable name. > > OK, poor example (as it wasn't self evident). Try this. > shortLINE is an object; it contains an object called leftPOINT with a > object value called X which can be set with method SET. > > n shortLINE leftPOINT X SET > > That is, object object object method. OK. So, I'm going to take one thing as a dogma: the only way to access the state inside an object is by calling one of its methods. This encapsulation is IMVHO (and not just me) one of the most basic principles of object orientation. [*] If you want to do something to the inside of shortLINE, you're going to have to add a method to shortLINE's to do it. Objects are passive, and naming an object pushes its address onto the stack. So, it'd be n shortLINE ( n a1) @leftPOINT ( n a2) setX I don't know if that's exactly what you meant, but it's my guess. I'd say that the @leftPoint method really shouldn't return the address of shortLINE's internal state, but neither would I do anything to prevent it. It's just bad style. Andrew. [*] There are two, as per Alan Kay: late binding of everything and encapsulation of an object's state
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 02:43 -0500 |
| Message-ID | <kOSdnS3PQK0jRpfEnZ2dnUU7-IPNnZ2d@supernews.com> |
| In reply to | #58603 |
Alex <alex@rivadpm.com> wrote: > There are some specific occasions when this doesn't work. How about > object A with method CUT and object B with method CUT. > > A CUT > B CUT > > How does CUT know how to find the CUT method in the object? Can we > efficiently compile this? Yes, of course. Dynamic method dispatch: standard object-oriented technology, in use for decades. > We're forced into duck typing (bleuch!) and the truly awful object > method system that Win32Forth uses. I don't know about Win32Forth, but I'd use a combination of inline caching and a hash lookup. This is conventional for OO languages. I wouldn't expect a significant overhead when compared with all the other work that a program has to do. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 13:05 +0100 |
| Message-ID | <oef58u$ft7$1@dont-email.me> |
| In reply to | #58619 |
On 5/4/2017 08:43, Andrew Haley wrote: > Alex <alex@rivadpm.com> wrote: >> There are some specific occasions when this doesn't work. How about >> object A with method CUT and object B with method CUT. >> >> A CUT >> B CUT >> >> How does CUT know how to find the CUT method in the object? Can we >> efficiently compile this? > > Yes, of course. Dynamic method dispatch: standard object-oriented > technology, in use for decades. Agreed. But; 1. The object doesn't need to be more complicated that a struct for this to require quite a lot of runtime overhead in method LEFT for structure RECTANGLE. MYRECT.LEFT not only makes it obvious, it makes it efficient at runtime. The amount of baggage at runtime that LEFT requires is not trivial. 2. It's (potentially) tickable. 3. We're also transferring the runtime overhead back into the recognizer at compile time where it belongs. > >> We're forced into duck typing (bleuch!) and the truly awful object >> method system that Win32Forth uses. > > I don't know about Win32Forth, but I'd use a combination of inline > caching and a hash lookup. This is conventional for OO languages. I > wouldn't expect a significant overhead when compared with all the > other work that a program has to do. It does use a similar technique, based on classes defined as mini wordlists plus a bit. It had (it's possible it still has, I've not checked in a number of years) a terrible hash function; the hashes for GET and SET collided. Hashes are notoriously difficult to test, as any cryptographer will tell you. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-05-04 15:10 +0300 |
| Message-ID | <oef5gn$fs9$1@dont-email.me> |
| In reply to | #58637 |
On 04/05/2017 15:05, Alex wrote: > It does use a similar technique, based on classes defined as mini > wordlists plus a bit. It had (it's possible it still has, I've not > checked in a number of years) a terrible hash function; the hashes for > GET and SET collided. Hashes are notoriously difficult to test, as any > cryptographer will tell you. But the hash colliding isn't an issue. Unless you expect a perfect hash function, any hash function will collide. So you check the bucket for a match...
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-05-04 13:25 +0100 |
| Message-ID | <oef6d4$js7$1@dont-email.me> |
| In reply to | #58639 |
On 5/4/2017 13:10, Ron Aaron wrote: > > > On 04/05/2017 15:05, Alex wrote: > >> It does use a similar technique, based on classes defined as mini >> wordlists plus a bit. It had (it's possible it still has, I've not >> checked in a number of years) a terrible hash function; the hashes for >> GET and SET collided. Hashes are notoriously difficult to test, as any >> cryptographer will tell you. > > But the hash colliding isn't an issue. Unless you expect a perfect hash > function, any hash function will collide. So you check the bucket for a > match... > It didn't check; or rather, it couldn't. The name was thrown away and only the hash remained. I didn't write it, although I did spend many hours debugging it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-05-04 15:33 +0300 |
| Message-ID | <oef6s9$lju$1@dont-email.me> |
| In reply to | #58642 |
On 04/05/2017 15:25, Alex wrote: > > It didn't check; or rather, it couldn't. The name was thrown away and > only the hash remained. I didn't write it, although I did spend many > hours debugging it. oy...
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 08:05 -0500 |
| Message-ID | <TPGdnQZAK46WupbEnZ2dnUU7-cfNnZ2d@supernews.com> |
| In reply to | #58637 |
Alex <alex@rivadpm.com> wrote: > On 5/4/2017 08:43, Andrew Haley wrote: >> Alex <alex@rivadpm.com> wrote: >>> There are some specific occasions when this doesn't work. How about >>> object A with method CUT and object B with method CUT. >>> >>> A CUT >>> B CUT >>> >>> How does CUT know how to find the CUT method in the object? Can we >>> efficiently compile this? >> >> Yes, of course. Dynamic method dispatch: standard object-oriented >> technology, in use for decades. > > Agreed. But; > > 1. The object doesn't need to be more complicated that a struct for this > to require quite a lot of runtime overhead in method LEFT for structure > RECTANGLE. MYRECT.LEFT not only makes it obvious, it makes it efficient > at runtime. The amount of baggage at runtime that LEFT requires is not > trivial. It's not huge either. LEFT is an action which must find the appropriate method to dispatch to in the A object. > 2. It's (potentially) tickable. Every word should be tickable, for sure. > 3. We're also transferring the runtime overhead back into the recognizer > at compile time where it belongs. If a compiler can tell what the type of A and B are, then it can through simple peephole optimization determine what method to call. If it can't then it'll have to do runtime dispatch, which isn't so bad. There's really no need for all this dotting. >>> We're forced into duck typing (bleuch!) and the truly awful object >>> method system that Win32Forth uses. >> >> I don't know about Win32Forth, but I'd use a combination of inline >> caching and a hash lookup. This is conventional for OO languages. I >> wouldn't expect a significant overhead when compared with all the >> other work that a program has to do. > > It does use a similar technique, based on classes defined as mini > wordlists plus a bit. It had (it's possible it still has, I've not > checked in a number of years) a terrible hash function; the hashes > for GET and SET collided. Hashes are notoriously difficult to test, > as any cryptographer will tell you. Right, but you can mess up anything. I don't think that there is any need for wordlists in all of this. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-09 15:54 +0000 |
| Message-ID | <xn0kps4ihq4sizj004@nntp.aioe.org> |
| In reply to | #58585 |
Mark Wills wrote: > On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: > > Mark Wills <markwills1970@gmail.com> wrote: > > > > > > Primary uses I see for them are: > > > > > > 1) Nice way to recognise and deal with floating point numbers in > > > source code. I.e. Instead of >f 3.141 we can just have 3.141 or > > > (if your system produces doubles from a number with a decimal > > > point (WTAF?) just f3.141 > > > > > > 2) Nice dotted OOP syntax > > > > I'm not convinced by 2). Forth's obvious equivalent of a.b.c or > > a.b.c() is A B C . It's not at all obvious to me that the dotted > > equivalent is better. > > > > Andrew. > > I agree that A B C is more Forthy, however, I'd argue it's less > readable; it's less obvious that C is a method of instance B etc. > > TRUE button1 font bold > TRUE button1.font.bold > > (IMO) the latter of the two examples is slightly more intuitive, What about button1 font-weight: bold That's more Smalltalk-like and very easy to read, IMO. CSS uses a similar syntax too. No need for TRUE. Just have button1 font-weigth: normal if it is not bold. Normal would be the default anyway. -- Rudy Velthuis http://www.rvelthuis.de "If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him." -- Cardinal Richelieu
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-09 11:10 -0500 |
| Message-ID | <DICdnYUBP6Cad4zEnZ2dnUU7-cudnZ2d@supernews.com> |
| In reply to | #58899 |
Rudy Velthuis <newsgroups@rvelthuis.de> wrote: > Mark Wills wrote: > >> On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: >> > Mark Wills <markwills1970@gmail.com> wrote: >> > > >> > > Primary uses I see for them are: >> > > >> > > 1) Nice way to recognise and deal with floating point numbers in >> > > source code. I.e. Instead of >f 3.141 we can just have 3.141 or >> > > (if your system produces doubles from a number with a decimal >> > > point (WTAF?) just f3.141 >> > > >> > > 2) Nice dotted OOP syntax >> > >> > I'm not convinced by 2). Forth's obvious equivalent of a.b.c or >> > a.b.c() is A B C . It's not at all obvious to me that the dotted >> > equivalent is better. >> >> I agree that A B C is more Forthy, however, I'd argue it's less >> readable; it's less obvious that C is a method of instance B etc. >> >> TRUE button1 font bold >> TRUE button1.font.bold >> >> (IMO) the latter of the two examples is slightly more intuitive, > > What about > > button1 font-weight: bold > > That's more Smalltalk-like and very easy to read, IMO. CSS uses a > similar syntax too. No need for TRUE. Just have > > button1 font-weigth: normal > > if it is not bold. Normal would be the default anyway. But the weight is passed on the stack. What, then, would you do? It's nasty to have methods parsing ahead in the input stream for operands, which is I presume what is happening here. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-05-10 11:49 +0000 |
| Message-ID | <xn0kptcmx33s9sm005@nntp.aioe.org> |
| In reply to | #58902 |
Andrew Haley wrote: > Rudy Velthuis <newsgroups@rvelthuis.de> wrote: > > Mark Wills wrote: > > > >> On Wednesday, 3 May 2017 15:02:10 UTC+1, Andrew Haley wrote: > >> > Mark Wills <markwills1970@gmail.com> wrote: > >> > > > >> > > Primary uses I see for them are: > >> > > > >> > > 1) Nice way to recognise and deal with floating point numbers > in >> > > source code. I.e. Instead of >f 3.141 we can just have > 3.141 or >> > > (if your system produces doubles from a number with > a decimal >> > > point (WTAF?) just f3.141 > >> > > > >> > > 2) Nice dotted OOP syntax > >> > > >> > I'm not convinced by 2). Forth's obvious equivalent of a.b.c or > >> > a.b.c() is A B C . It's not at all obvious to me that the dotted > >> > equivalent is better. > >> > >> I agree that A B C is more Forthy, however, I'd argue it's less > >> readable; it's less obvious that C is a method of instance B etc. > >> > >> TRUE button1 font bold > >> TRUE button1.font.bold > >> > >> (IMO) the latter of the two examples is slightly more intuitive, > > > > What about > > > > button1 font-weight: bold > > > > That's more Smalltalk-like and very easy to read, IMO. CSS uses a > > similar syntax too. No need for TRUE. Just have > > > > button1 font-weigth: normal > > > > if it is not bold. Normal would be the default anyway. > > But the weight is passed on the stack. Ok, then the other way around: normal font-weight: button1 Or button1 normal font-weight -- Rudy Velthuis http://www.rvelthuis.de "May your fondest wish be granted." -- Traditional Chinese curse
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-05-04 16:14 +0000 |
| Message-ID | <2017May4.181413@mips.complang.tuwien.ac.at> |
| In reply to | #58584 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Mark Wills <markwills1970@gmail.com> wrote:
>> 2) Nice dotted OOP syntax
>
>I'm not convinced by 2). Forth's obvious equivalent of a.b.c or
>a.b.c() is A B C . It's not at all obvious to me that the dotted
>equivalent is better.
I would prefer it if we could just write A B C. And where this is
viable, I have advocated it and implemented it: We had long
discussions about "object selector" (with the object passed on the
stack) vs. Neon-Style OO syntax.
But in an OO system, we get a technical problem: We often want the
same field names in different, unrelated classes, e.g., we want VAL in
a linked-list and in a tree class.
For simple structs, my solution was to use composite names, e.g.,
LIST-VAL and TREE-VAL. But once we have inheritance, this does not
really work. E.g., if you have classes M>N>O>P>Q (where, for A>B, A
is a superclass of B), and you want to define a field VAL in N, that
would lead to calling it N-VAL; but it's also a field for classes O,
P, and Q through inheritance.
A programmer accessing the VAL field of Q has the following plausible
names for the field: M-VAL N-VAL O-VAL P-VAL and Q-VAL. So having to
remember that it is N-VAL puts a mental load on the programmer. If
the programmer writes N-VAL, that also reduces the ability of
refactoring the class hierarchy. And, as one of the participants at
the Forth-Tagung 2017 pointed out, this convention also costs a
significant amount of memory on small systems (IIRC 500 bytes on a
16KB system).
There have been quite a number of attempts to deal with this problem
over the years.
1) Bernd Paysan implements overloading resolution in his OOF with
STATE-smart parsing words. Need I say more?
2) In my objects.fs I make the fields only visible inside the class
definition (i.e., in a subclass of LIST you would see the VAL of LIST,
while in a subclass of TREE you would see the VAL of TREE). The
disadvantage is that you cannot easily access the fields during
debugging; nor can you access fields of an object of a class outside
the class definition easily.
3) Manfred Mahlow proposed the prelude system for dealing with this
problem (where each word sets up the search order for looking up the
next word, but afterward the search order reverts to the normal search
order). This needs special support by the Forth system (at least
partly implemented in Gforth), and the system then does not behave
like a normal Forth system in non-obvious ways. E.g., in A B, where A
is a prelude to B, if you put a comment in between, "A ( x ) B", it no
longer works (or you need extra complications to make it work).
4) And VFX has a dot-parser.
1 and 3 are solutions that make the result look like Forth, but
actually are at least as far away from ordinary Forth as the
dot-parser. The use of the dot-notation at least makes it obvious
what is going on. The solution for our VAL problem could look as
Q.VAL (or Q:VAL). But typically dot-parsers have gone further and
support sequences of field accesses; maybe something like
TREE:LEFT.VAL. I guess as a purist one would rather write this as
TREE:LEFT TREE:VAL. I guess we will see various variants of
dot-parsers, and we will see which one wins out (if any; but at least
it seems that, after 30 years, we have overcome the Neon syntax, so
there is progress, even if glacial).
The same problem occurs with the C interface: different C structs may
have the same field names.
- 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 2017: http://www.euroforth.org/ef17/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-04 13:02 -0500 |
| Message-ID | <N8SdnSyDg4gE8ZbEnZ2dnUU7-LHNnZ2d@supernews.com> |
| In reply to | #58678 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Mark Wills <markwills1970@gmail.com> wrote: >>> 2) Nice dotted OOP syntax >> >>I'm not convinced by 2). Forth's obvious equivalent of a.b.c or >>a.b.c() is A B C . It's not at all obvious to me that the dotted >>equivalent is better. > > I would prefer it if we could just write A B C. And where this is > viable, I have advocated it and implemented it: We had long > discussions about "object selector" (with the object passed on the > stack) vs. Neon-Style OO syntax. > > But in an OO system, we get a technical problem: We often want the > same field names in different, unrelated classes, e.g., we want VAL in > a linked-list and in a tree class. So @VAL is a method, and uses dynamic binding, surely. Where's the problem? > For simple structs, my solution was to use composite names, e.g., > LIST-VAL and TREE-VAL. But once we have inheritance, this does not > really work. E.g., if you have classes M>N>O>P>Q (where, for A>B, A > is a superclass of B), and you want to define a field VAL in N, that > would lead to calling it N-VAL; but it's also a field for classes O, > P, and Q through inheritance. > > A programmer accessing the VAL field of Q has the following plausible > names for the field: M-VAL N-VAL O-VAL P-VAL and Q-VAL. So having to > remember that it is N-VAL puts a mental load on the programmer. If > the programmer writes N-VAL, that also reduces the ability of > refactoring the class hierarchy. And, as one of the participants at > the Forth-Tagung 2017 pointed out, this convention also costs a > significant amount of memory on small systems (IIRC 500 bytes on a > 16KB system). > > There have been quite a number of attempts to deal with this problem > over the years. > > 1) Bernd Paysan implements overloading resolution in his OOF with > STATE-smart parsing words. Need I say more? :-) > 2) In my objects.fs I make the fields only visible inside the class > definition (i.e., in a subclass of LIST you would see the VAL of LIST, > while in a subclass of TREE you would see the VAL of TREE). The > disadvantage is that you cannot easily access the fields during > debugging; nor can you access fields of an object of a class outside > the class definition easily. That sounds right. The fact that no-one can easily access fields of an object without calling that object's methods is a feature, not a bug. (IMVHO, dogmatically.) Not that I'd do anything active to prevent such an access (this is Forth) but there's certainly no need to support it either. It's just bad OO style. If something should be changed from outside, setter and getter methods are conventional, and can even automagically be generated. Field names are local to the definition of an object. Is it actually necessary to hide them, though? I suppose it saves confusion, which must be a good thing, but presumably if they can be hidden they can also be revealed for debugging. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-05 23:29 +0000 |
| Message-ID | <oej1s0$j6c$1@dont-email.me> |
| In reply to | #58680 |
Am Thu, 04 May 2017 13:02:01 -0500 schrieb Andrew Haley: > The fact that no-one can easily access fields of an object without > calling that object's methods is a feature, not a bug. (IMVHO, > dogmatically.) The problem does not go away, because methods have the same properties as fields: By extending a class, you can add more methods just as well as more fields. Calling a method that doesn't belong to the class is just as wrong as accessing a field that doesn't belong to that class. BerndOOF handles checking method calls just the same way as handling fields: They all live in a vocabulary that belongs to the class. If it's there, you are allowed to use it, if not, it's simply a "not found" error. The one-shot switch for the vocabulary in 1994 Standard Forth (when BerndOOF was written) was state-smart, no other solution available. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-07 03:56 -0500 |
| Message-ID | <BdKdne_S8sfXfJPEnZ2dnUU7-bednZ2d@supernews.com> |
| In reply to | #58721 |
Bernd Paysan <bernd@net2o.de> wrote: > Am Thu, 04 May 2017 13:02:01 -0500 schrieb Andrew Haley: > >> The fact that no-one can easily access fields of an object without >> calling that object's methods is a feature, not a bug. (IMVHO, >> dogmatically.) > > The problem does not go away, because methods have the same properties as > fields: By extending a class, you can add more methods just as well as > more fields. Calling a method that doesn't belong to the class is just > as wrong as accessing a field that doesn't belong to that class. If the method doesn't beling to the class you'll get an exception. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Date | 2017-05-07 22:42 +0000 |
| Message-ID | <oeo7ru$3p2$1@dont-email.me> |
| In reply to | #58759 |
Am Sun, 07 May 2017 03:56:42 -0500 schrieb Andrew Haley: > If the method doesn't beling to the class you'll get an exception. Only if you do run-time checking... And we are Forthers, we don't do run- time checking. So in a vtable-based approach if the method is not defined in the class, because it belongs to a completely different class, and there's a method defined in that slot in the vtable, this method is called. It might or might not lead to an exception. It's just like when you access a member variable that is not part of the object, it will access some memory, either within or beyond the object. That's why people like to use vocabularies to make sure only those methods and fields are visible that make actually sense in that context. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-05-08 04:08 -0500 |
| Message-ID | <uuKdnfUCcLkFqI3EnZ2dnUU7-SPNnZ2d@supernews.com> |
| In reply to | #58794 |
Bernd Paysan <bernd@net2o.de> wrote: > Am Sun, 07 May 2017 03:56:42 -0500 schrieb Andrew Haley: >> If the method doesn't beling to the class you'll get an exception. > > Only if you do run-time checking... And we are Forthers, we don't do > run-time checking. The dynamic runtime lookup tradition of OOP in Forth is just as venerable as the static wordlist-based scheme, and IMO a much simpler and more suitable model. With inline caches it can be fast, sometimes as fast as vtable lookup, and avoids all that messing about with wordlists and such. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-05-03 08:51 -0700 |
| Message-ID | <912bef46-5af8-484b-bf9a-3eccc48ab754@googlegroups.com> |
| In reply to | #58580 |
On Wednesday, May 3, 2017 at 7:03:44 AM UTC-5, Mark Wills wrote: > Primary uses I see for them are: > > 1) Nice way to recognise and deal with floating point numbers in source > code. I.e. Instead of >f 3.141 we can just have 3.141 or (if your > system produces doubles from a number with a decimal point (WTAF?) > just f3.141 huh? Or more verbosely: What does ">f 3.141" mean? Is >f a parsing word that pushes a floating point number? Why would you ever use that instead of 3.141e ? If "f3.141" is a floating point number, how is this better than 3.141e ? What does "WTAF" mean? And why are you saying it in reply to a system producing doubles from a number with a decimal point? Isn't that virtually all systems? When I've wanted to have a bunch of floating point literals in code, f.e. for OpenGL matrices and coordinates, I've just written a parsing word to handle the nicer syntax, putting the numbers in storage, and also doing stuff like translate - to 0e to reduce noise. This idea also translates to 'literal mazes' for games, where each line is padded appropriately before stored, which would be a lot messier for a recognizer. With such you have exceptional parsing in a clearly defined area (preceded by a parsing word) and you don't have to worry about some random part of your program or a loaded library having its doubles interpreted as floats. > 2) Nice dotted OOP syntax Is this damning with faint praise? I would say that recognizers are a nice way to implement the hooked and exceptional parsers that Forths systems actually have. Recognizers don't replace 'simplicity' with 'complexity', but 'system-specific complexity' with 'standard complexity'. This is a good replacement as it encourages people to actually use those hooks to produce better code. It's also a worrying replacement because it encourages people to actually use those hooks to produce more obscure code. On Wednesday, May 3, 2017 at 9:54:51 AM UTC-5, minf...@arcor.de wrote: > Am Mittwoch, 3. Mai 2017 15:57:13 UTC+2 schrieb Andrew Haley: > > Sure, but then you're screwed anyway. I've never used a Forth I > > didn't have the source code for, and neither would I want to. One > > great benefit of a simple system is that you can easily change it, > > and > > you don't have to depend on high priests in their ivory tower to > > consider your request. > > > > Sure, but there is a reason behind, when you're not in a > One-Man-Show. The core system should never be messed around with by > engineers, like any firmware or operating system internals. That's > the realm of software development. I'm in a Multi-Man-Show, and coworkers of mine have pushes patches to Apache, the Linux kernel, and cPanel, among others. Software has bugs. Software also has things that hurt a lot like bugs do: implicit expectations about how it'll be used, which can get violated on the ground. For example, cPanel has Apache perform a graceful restart, a reload of its configuration file, immediately after a change to it. If a reseller writes a script to add 3600 new clients within an hour, cPanel will have Apache reload its configuration 3600 times in an hour. Why? Because "configurations are small" and "Apache loads its configuration really fast" and you don't need to think about it as if it were an action that takes time. Meanwhile on some of our systems it can take several minutes for Apache to reload its configuration, so 3600 restarts would result in Apache being completely unresponsive for *hours*. There isn't some level of professionalism beyond which everything can be neatly solved with money. Source helps troubleshooting, it makes up for bad documentation (I admit I'd prefer good documentation), it lets you directly fix something without waiting on action from a third party, and it lets you invest in improvements that you wouldn't think to make without a good understand of the source and that wouldn't be offered to you by people without a good understanding of your particular circumstances.
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web