Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48645 > unrolled thread
| Started by | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| First post | 2016-07-01 16:10 +0000 |
| Last post | 2016-08-14 07:19 -0700 |
| Articles | 20 on this page of 186 — 29 participants |
Back to article view | Back to comp.lang.forth
3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-01 16:10 +0000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-01 11:21 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-01 11:58 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-01 12:53 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-01 16:05 -0400
Re: 3rd RfD: Quotations Cecil Bayona <cbayona@cbayona.com> - 2016-07-01 19:00 -0500
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-01 18:22 -0700
Re: 3rd RfD: Quotations Cecil Bayona <cbayona@cbayona.com> - 2016-07-01 21:16 -0500
Re: 3rd RfD: Quotations Wasell <from_usenet@wasell.eu> - 2016-07-02 13:04 +0200
Re: 3rd RfD: Quotations Cecil Bayona <cbayona@cbayona.com> - 2016-07-02 09:39 -0500
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-07-02 16:33 +0100
Re: 3rd RfD: Quotations Cecil Bayona <cbayona@cbayona.com> - 2016-07-02 11:50 -0500
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-02 10:45 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-02 19:24 -0400
Re: 3rd RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-03 11:48 +0100
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-03 07:08 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-03 11:49 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-04 08:25 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-04 16:57 -0700
Re: 3rd RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-05 07:40 +0100
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-05 01:38 -0700
Re: 3rd RfD: Quotations alex@rivadpm.com - 2016-07-05 01:33 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-05 02:28 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-05 10:06 -0400
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-07-05 20:57 +0100
Re: 3rd RfD: Quotations Ron Aaron <rambamist@gmail.com> - 2016-07-06 00:12 +0300
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-07-05 22:45 +0100
Re: 3rd RfD: Quotations Ron Aaron <rambamist@gmail.com> - 2016-07-06 10:50 +0300
Re: 3rd RfD: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-06 03:31 -0500
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-08 09:07 -0700
Re: 3rd RfD: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-07-04 21:08 +0100
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-04 09:10 -0700
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-07-02 19:24 +0100
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-02 16:19 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-02 23:18 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-02 21:54 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-03 03:10 -0400
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-07-03 09:35 +0100
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-02 19:19 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-03 01:45 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-03 11:52 -0400
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-02 19:10 -0400
Re: 3rd RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2016-07-02 13:27 -1000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-02 16:54 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-02 23:27 -0400
Re: 3rd RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-05 00:30 +0000
Re: 3rd RfD: Quotations "HAA" <someone@microsoft.com> - 2016-07-08 21:15 +1000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-08 07:39 -0700
Re: 3rd RfD: Quotations "HAA" <someone@microsoft.com> - 2016-07-09 17:08 +1000
Re: 3rd RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2016-07-08 23:22 -1000
Re: 3rd RfD: Quotations "HAA" <someone@microsoft.com> - 2016-07-08 20:42 +1000
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-07-01 21:51 +0100
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-01 17:57 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-01 18:47 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-02 07:55 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-04 17:03 -0700
Re: 3rd RfD: Quotations alex@rivadpm.com - 2016-07-05 01:38 -0700
Re: 3rd RfD: Quotations rickman <gnuarm@gmail.com> - 2016-07-05 10:16 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-05 10:48 -0700
Re: 3rd RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2016-07-05 20:18 +0200
Re: 3rd RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-05 00:42 +0000
Re: 3rd RfD: Quotations julian.fondren@endurance.com - 2016-08-04 19:44 -0700
Re: 3rd RfD: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2016-08-20 22:08 +0000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-06 21:01 -0700
Re: 3rd RfD: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-07-07 07:54 +0000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-08 08:17 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-08 08:41 -0700
Re: 3rd RfD: Quotations Julian Fondren <ayrnieu@gmail.com> - 2016-07-08 10:21 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-08 14:29 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-08 22:28 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-09 03:56 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-09 09:51 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-13 01:25 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-13 01:56 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-13 02:09 -0700
Re: 3rd RfD: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-07-13 14:04 +0000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-14 00:32 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-14 01:25 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-16 14:52 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-16 20:25 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-18 12:46 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-18 14:38 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-18 16:03 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-18 17:27 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-14 02:46 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-15 08:33 -0700
Re: 3rd RfD: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-07-15 16:59 +0000
Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-15 23:30 -0700
Universal Delimiters - was Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-16 02:42 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-16 05:47 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2016-07-16 15:41 +0200
Re: Universal Delimiters - was Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-16 07:16 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-16 07:27 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-16 09:52 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-16 11:46 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-17 03:11 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-17 03:18 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-17 03:47 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-17 05:43 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-17 06:00 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-17 08:32 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-17 23:49 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-18 00:39 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-16 07:57 -0700
Re: Universal Delimiters - was Re: 3rd RfD: Quotations Coos Haak <chforth@hccnet.nl> - 2016-07-18 12:18 +0200
Re: Universal Delimiters - was Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-18 04:04 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-10 21:23 -0700
Re: 3rd RfD: Quotations Lars Brinkhoff <lars.spam@nocrew.org> - 2016-07-09 14:30 +0200
Re: 3rd RfD: Quotations mhx@iae.nl - 2016-07-09 05:51 -0700
Re: 3rd RfD: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-09 09:01 -0500
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-09 07:40 -0700
Re: 3rd RfD: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-09 12:27 -0500
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-09 11:24 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-30 02:03 -0700
Re: 3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-09 14:36 +0000
Re: 3rd RfD: Quotations Håkan Thörngren <hth313@gmail.com> - 2016-07-09 12:58 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-09 21:59 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-09 23:11 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-10 00:14 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-12 01:06 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-12 05:31 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-12 09:00 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-13 03:44 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-13 11:36 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-13 23:03 -0700
Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-07-14 01:23 -0700
Re: 3rd RfD: Quotations "Elizabeth D. Rather" <erather@forth.com> - 2016-07-12 08:57 -1000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-12 22:53 -0700
Re: 3rd RfD: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-07-11 01:09 +0000
Re: 3rd RfD: Quotations Paul Rubin <no.email@nospam.invalid> - 2016-07-10 18:18 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-11 01:35 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-10 18:18 -0700
Re: 3rd RfD: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-07-11 08:24 +0000
Re: 3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-10 06:53 +0000
Re: 3rd RfD: Quotations Håkan Thörngren <hth313@gmail.com> - 2016-07-10 00:53 -0700
Re: 3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-10 16:57 +0000
Re: 3rd RfD: Quotations franck.bensusan@gmail.com - 2016-07-10 02:26 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-10 06:49 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-10 11:04 -0700
Re: 3rd RfD: Quotations JennyB <jennybrien@googlemail.com> - 2016-07-10 12:51 -0700
Re: 3rd RfD: Quotations franck.bensusan@gmail.com - 2016-07-10 13:21 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-07-10 13:23 -0700
3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-28 16:56 +0000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-07-28 16:29 -0700
Re: 3rd RfD: Quotations "WJ" <w_a_x_man@yahoo.com> - 2016-07-29 00:50 +0000
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-11 12:15 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-08-11 13:25 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-11 20:57 -0700
Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-08-11 13:59 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-11 21:11 -0700
Re: 3rd RfD: Quotations Julian Fondren <julian.fondren@gmail.com> - 2016-08-12 00:30 -0700
Re: 3rd RfD: Quotations foxaudioresearch@gmail.com - 2016-08-13 11:33 -0700
Re: 3rd RfD: Quotations Coos Haak <htrofhc@gmail.com> - 2016-08-13 21:22 +0200
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-12 11:05 -0700
Re: 3rd RfD: Quotations humptydumpty <ouatubi@gmail.com> - 2016-08-13 07:27 -0700
Re: 3rd RfD: Quotations dhoffman888@gmail.com - 2016-08-13 04:01 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-13 20:24 -0700
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-14 08:22 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-14 07:10 -0700
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-14 10:36 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-14 13:57 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-14 14:17 -0700
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-14 20:12 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-14 18:55 -0700
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-15 06:17 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-15 17:37 -0700
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-17 06:16 -0400
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-17 19:58 -0700
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-18 07:52 -0400
Re: 3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-18 07:50 +0000
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-18 07:03 -0400
Re: 3rd RfD: Quotations Ron Aaron <rambamist@gmail.com> - 2016-08-15 07:01 +0300
Re: 3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 07:49 +0000
Re: 3rd RfD: Quotations Ron Aaron <rambamist@gmail.com> - 2016-08-15 11:48 +0300
Duck Typing (was: 3rd RfD: Quotations) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 09:53 +0000
Re: Duck Typing Ron Aaron <rambamist@gmail.com> - 2016-08-15 13:14 +0300
Re: Duck Typing Ron Aaron <rambamist@gmail.com> - 2016-08-15 17:42 +0300
Re: 3rd RfD: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-15 08:10 +0000
Re: 3rd RfD: Quotations Doug Hoffman <glidedog@gmail.com> - 2016-08-15 05:47 -0400
Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-08-15 12:10 +0100
Re: 3rd RfD: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-08-18 08:38 -0500
Piumarta object model (was Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-08-19 20:44 +0100
Re: Piumarta object model (was Re: 3rd RfD: Quotations Alex McDonald <alex@rivadpm.com> - 2016-08-19 20:58 +0100
Re: 3rd RfD: Quotations franck.bensusan@gmail.com - 2016-08-15 07:04 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-14 07:25 -0700
Re: 3rd RfD: Quotations hughaguilar96@gmail.com - 2016-08-14 07:19 -0700
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 13:57 -0700 |
| Message-ID | <3244c79f-4cfd-47cd-a398-4eba1c60912d@googlegroups.com> |
| In reply to | #50087 |
On Sunday, August 14, 2016 at 7:36:16 AM UTC-7, Doug Hoffman wrote:
> On 8/14/16 10:10 AM, hughaguilar96@gmail.com wrote:
> > This is what I said:
> > On Saturday, August 13, 2016 at 8:24:32 PM UTC-7, hughag...@gmail.com wrote:
> >> I read the "general comments" for that OOP package:
>
> Apparently that's all you read. Everything you say below about FMS is as
> wrong as your statement that it would run "2 orders of magnitude
> slower". That's 100+ times slower. You are 2 orders of magnitude wrong
> with that assumption. I've measured.
>
> >> "All message sends are by default dynamically resolved to the proper method at run time."
> ...
> Only during development. That check is turned off for final code.
Why does it say "at run time" if it is actually done at compile-time? Which is it?
Duck-typing is done at run-time --- this can't be turned off.
How is your HAS-IS function going to work on an arbitrary object at compile-time??? If you don't have HAS-IS then you don't have duck-typing --- that is what SmallTalk is all about.
> > Another advantage of [EACH ... ]EACH is that I hold the next node on the return-stack throughout so that if the current node gets clobbered we don't lose the next node. You aren't doing that. You assume that EACH: is going to work for obtaining the next node --- it won't though if the current node gets clobbered --- this can happen, for example, if the current node gets moved to a different list so its .FORE pointer is no longer valid. This business of holding the next node aside is also done in EACH and |EACH internally, so they allow the current node to get clobbered and they are still able to move on to the next node.
> > Just guessing, I would expect that your EACH: is defined like this:
> > : each: ( node -- node true | false )
> > dup 0<> \ -- node flag
> > dup 0= if nip then ;
If your EACH: is written like this, then I was wrong to say that you can't clobber the node --- you can because you have already obtained the next-node.
> > Another advantage of [EACH and ]EACH is that the code in between has access to the data on the data-stack from outside of the loop, without any internal data getting in the way. You aren't doing that. You have the current node sitting on top of the data getting in the way. This is the same problem that I found in FFL --- that has been fixed now in FFL (for singly linked lists; I haven't checked any of their other data-structures to find out if they still have this problem or not). This business of allowing the code in between to access the data-stack is also done in EACH and |EACH internally.
This is still true however. Your EACH: is holding its internal data on the data-stack sitting on top of the user's data --- this prevents the user from getting access to his own data.
Effectively, you are forcing the user to use local variables to communicate between the code inside of your loop and the code outside of your loop. In my system, this is an option, but it is not forced. For light-weight cases you just want to use the data-stack rather than local variables, but your system forces every program to use the heavy-weight solution with local variables.
Here is a light-weight case:
: chick-counter ( head -- chicks )
0
swap r[ .gender @ [char] F = if 1+ then ]r |each ;
Here is a test:
try hottie.4th
Including hottie.4th ok
people chick-counter ok-1
. 5 ok
With your EACH: how are you going to do this without local variables?
BTW: Why are you promoting FMS? Did you write it?
I still think that my novice-package is way ahead of any Forth OOP package that anybody else has written. Your FMS doesn't have macros available, so you are forcing your user to manually type out BEGIN WHILE REPEAT for every loop --- that is pretty crude.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 14:17 -0700 |
| Message-ID | <038156a7-5be4-4115-8eb4-ad1ce3e1d2a2@googlegroups.com> |
| In reply to | #50098 |
On Sunday, August 14, 2016 at 1:57:56 PM UTC-7, hughag...@gmail.com wrote:
> Here is a light-weight case:
>
> : chick-counter ( head -- chicks )
> 0
> swap r[ .gender @ [char] F = if 1+ then ]r |each ;
>
> Here is a test:
>
> try hottie.4th
> Including hottie.4th ok
> people chick-counter ok-1
> . 5 ok
>
> With your EACH: how are you going to do this without local variables?
My |EACH does work in this light-weight case, but it is somewhat inefficient. For such light-weight problems it is generally more efficient to use the macros:
: macro-chick-counter ( head -- chicks )
0
swap each[ .gender @ [char] F = if 1+ then ]each ;
Here is a test:
try hottie.4th
Including hottie.4th ok
people macro-chick-counter ok-1
. 5 ok
Here is the generated code for both versions:
see chick-counter
CHICK-COUNTER
( 004E36A0 8D6DFC ) LEA EBP, [EBP+-04]
( 004E36A3 C7450000000000 ) MOV DWord Ptr [EBP], 00000000
( 004E36AA E8E1BEFFFF ) CALL 004DF590 (R:)
( 004E36AF E916000000 ) JMP 004E36CA
( 004E36B4 837B0846 ) CMP [EBX+08], 46
( 004E36B8 8B5D00 ) MOV EBX, [EBP]
( 004E36BB 8D6D04 ) LEA EBP, [EBP+04]
( 004E36BE 0F8501000000 ) JNZ/NE 004E36C5
( 004E36C4 43 ) INC EBX
( 004E36C5 E896BEFFFF ) CALL 004DF560 REXIT
( 004E36CA E831C8FFFF ) CALL 004DFF00 |EACH
( 004E36CF C3 ) NEXT,
( 48 bytes, 12 instructions )
ok
see |each
|EACH
( 004DFF00 8BD4 ) MOV EDX, ESP
( 004DFF02 53 ) PUSH EBX
( 004DFF03 6A00 ) PUSH 00
( 004DFF05 52 ) PUSH EDX
( 004DFF06 57 ) PUSH EDI
( 004DFF07 8BFC ) MOV EDI, ESP
( 004DFF09 81EC00000000 ) SUB ESP, 00000000
( 004DFF0F 8B5D00 ) MOV EBX, [EBP]
( 004DFF12 8D6D04 ) LEA EBP, [EBP+04]
( 004DFF15 90 ) NOP
( 004DFF16 90 ) NOP
( 004DFF17 90 ) NOP
( 004DFF18 85DB ) TEST EBX, EBX
( 004DFF1A 750B ) JNZ/NE 004DFF27
( 004DFF1C 8B5D00 ) MOV EBX, [EBP]
( 004DFF1F 8D6D04 ) LEA EBP, [EBP+04]
( 004DFF22 E91E000000 ) JMP 004DFF45
( 004DFF27 8B13 ) MOV EDX, 0 [EBX]
( 004DFF29 895708 ) MOV [EDI+08], EDX
( 004DFF2C 8D6DFC ) LEA EBP, [EBP+-04]
( 004DFF2F 895D00 ) MOV [EBP], EBX
( 004DFF32 8B5F0C ) MOV EBX, [EDI+0C]
( 004DFF35 E806F7FFFF ) CALL 004DF640 REX
( 004DFF3A 8D6DFC ) LEA EBP, [EBP+-04]
( 004DFF3D 895D00 ) MOV [EBP], EBX
( 004DFF40 8B5F08 ) MOV EBX, [EDI+08]
( 004DFF43 EBD3 ) JMP 004DFF18
( 004DFF45 8B6704 ) MOV ESP, [EDI+04]
( 004DFF48 8B3F ) MOV EDI, 0 [EDI]
( 004DFF4A C3 ) NEXT,
( 75 bytes, 30 instructions )
ok
see macro-chick-counter
MACRO-CHICK-COUNTER
( 004E3700 8D6DFC ) LEA EBP, [EBP+-04]
( 004E3703 C7450000000000 ) MOV DWord Ptr [EBP], 00000000
( 004E370A 90 ) NOP
( 004E370B 90 ) NOP
( 004E370C 90 ) NOP
( 004E370D 90 ) NOP
( 004E370E 90 ) NOP
( 004E370F 90 ) NOP
( 004E3710 85DB ) TEST EBX, EBX
( 004E3712 0F841F000000 ) JZ/E 004E3737
( 004E3718 8B13 ) MOV EDX, 0 [EBX]
( 004E371A 52 ) PUSH EDX
( 004E371B 837B0846 ) CMP [EBX+08], 46
( 004E371F 8B5D00 ) MOV EBX, [EBP]
( 004E3722 8D6D04 ) LEA EBP, [EBP+04]
( 004E3725 0F8501000000 ) JNZ/NE 004E372C
( 004E372B 43 ) INC EBX
( 004E372C 5A ) POP EDX
( 004E372D 8D6DFC ) LEA EBP, [EBP+-04]
( 004E3730 895D00 ) MOV [EBP], EBX
( 004E3733 8BDA ) MOV EBX, EDX
( 004E3735 EBD9 ) JMP 004E3710
( 004E3737 8B5D00 ) MOV EBX, [EBP]
( 004E373A 8D6D04 ) LEA EBP, [EBP+04]
( 004E373D C3 ) NEXT,
( 62 bytes, 25 instructions )
ok
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-14 20:12 -0400 |
| Message-ID | <57b108dd$0$298$14726298@news.sunsite.dk> |
| In reply to | #50098 |
On 8/14/16 4:57 PM, hughaguilar96@gmail.com wrote:
>>>> "All message sends are by default dynamically resolved to the proper method at run time."
>> ...
>> Only during development. That check is turned off for final code.
>
> Why does it say "at run time" if it is actually done at compile-time? Which is it?
Two different issues:
1) dynamic dispatch (run time)
2) invalid message send error detection
1) is always there
2) can be turned on and off with a compile time switch
> Duck-typing is done at run-time --- this can't be turned off.
Correct. See 1) above.
> How is your HAS-IS function going to work on an arbitrary object at
> compile-time??? If you don't have HAS-IS then you don't have duck-typing
--- that is what SmallTalk is all about.
>
>>> Another advantage of [EACH ... ]EACH is that I hold the next node on the return-stack throughout so that if the current node gets clobbered we don't lose the next node. You aren't doing that. You assume that EACH: is going to work for obtaining the next node --- it won't though if the current node gets clobbered --- this can happen, for example, if the current node gets moved to a different list so its .FORE pointer is no longer valid. This business of holding the next node aside is also done in EACH and |EACH internally, so they allow the current node to get clobbered and they are still able to move on to the next node.
>
>>> Just guessing, I would expect that your EACH: is defined like this:
>>> : each: ( node -- node true | false )
>>> dup 0<> \ -- node flag
>>> dup 0= if nip then ;
>
> If your EACH: is written like this, then I was wrong to say that you
> can't clobber the node --- you can because you have already obtained the
> next-node.
No, EACH: looks nothing like the above.
The stack effect for EACH: ( -- item true | false )
EACH: is a message that is sent to a list or array object.
The item it returns depends on the list, in the case of
an object-list it returns an object.
>>> Another advantage of [EACH and ]EACH is that the code in between
>>> has
>>> access to the data on the data-stack from outside of the loop, without
>>> any internal data getting in the way. You aren't doing that. You have
>>> the current node sitting on top of the data getting in the way. This is
>>> the same problem that I found in FFL --- that has been fixed now in FFL
>>> (for singly linked lists; I haven't checked any of their other
>>> data-structures to find out if they still have this problem or not).
>>> This business of allowing the code in between to access the data-stack
>>> is also done in EACH and |EACH internally.
>
> This is still true however. Your EACH: is holding its internal data on
> the data-stack sitting on top of the user's data --- this prevents the
> user from getting access to his own data.
No. EACH: is just a message with no 'internal data'.
All EACH: needs is an object on the stack that 'knows'
the EACH: message.
In this case it's a list object.
> Effectively, you are forcing the user to use local variables to
> communicate between the code inside of your loop and the code outside of
> your loop.
No.
> Here is a light-weight case:
>
> : chick-counter ( head -- chicks )
> 0
> swap r[ .gender @ [char] F = if 1+ then ]r |each ;
>
> Here is a test:
>
> try hottie.4th
> Including hottie.4th ok
> people chick-counter ok-1
> . 5 ok
>
> With your EACH: how are you going to do this without local variables?
: chick-counter ( list -- chicks )
0
begin
over each:
while
is-a chick if 1+ then
repeat nip ;
or
: chick-counter ( list -- chicks )
>r 0
begin
r@ each:
while
is-a chick if 1+ then
repeat r> drop ;
or
0 :noname is-a chick if 1+ then ; people map: .
or (I won't bother with several other ways)
Note that one could easily create a gender field and use that in a
similar fashion. But the IS-A function is so simple to use here.
> BTW: Why are you promoting FMS?
So people are aware that it exists in the FLAG library in case they want
an OOP extension with its capabilities.
> Did you write it?
Yes.
> I still think that my novice-package is way ahead of any Forth OOP
> package that anybody else has written. Your FMS doesn't have macros
> available, so you are forcing your user to manually type out BEGIN WHILE
> REPEAT for every loop --- that is pretty crude.
It's simple Forth. The FMS OOP extension is designed to work seamlessly
*with* Forth. It does not try to do everything. Only use it where
appropriate. Btw, see the MAP: message used above.
-Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 18:55 -0700 |
| Message-ID | <c3a4f3c8-fece-45c3-8ae0-7e08daffca9e@googlegroups.com> |
| In reply to | #50111 |
On Sunday, August 14, 2016 at 5:12:15 PM UTC-7, Doug Hoffman wrote:
> On 8/14/16 4:57 PM, hughaguilar96@gmail.com wrote:
> >>> Just guessing, I would expect that your EACH: is defined like this:
> >>> : each: ( node -- node true | false )
> >>> dup 0<> \ -- node flag
> >>> dup 0= if nip then ;
>
> No, EACH: looks nothing like the above.
> The stack effect for EACH: ( -- item true | false )
> EACH: is a message that is sent to a list or array object.
> The item it returns depends on the list, in the case of
> an object-list it returns an object.
You are responding to a post that I deleted. How can you even find a deleted post??? Why would you want to? Obviously, I deleted that post because I had a mistake in it. For you to somehow obtain my deleted post and quote the mistaken part, seems like a cheap shot. This is what I said in the post that I didn't delete:
On Sunday, August 14, 2016 at 7:25:25 AM UTC-7, hughag...@gmail.com wrote:
> Just guessing, I would expect that your EACH: is defined like this:
> : each: ( node -- next-node node true | false )
> dup if
> dup .fore @ \ -- node next-node
> swap true
> then ;
This is your function:
: test ( list -- )
0 0 0 0 { chicks tens nines eights }
begin
dup each:
while
dup is-a chick if chicks 1+ to chicks
( obj) hotness:
dup 8 = if eights 1+ to eights then
dup 9 = if nines 1+ to nines then
10 = if tens 1+ to tens then
else drop then
repeat
cr ." total people: " ( list) size: .
cr ." total chicks: " chicks .
cr ." level 10 chicks: " tens .
cr ." level 9 chicks: " nines .
cr ." level 8 chicks: " eights .
;
Simplified, your function looks like this:
: test ( list -- )
begin \ -- list
dup each: \ -- new-list list true | false
while \ -- new-list list
drop \ -- new-list \ this is the effect of the testing code
repeat
drop ; \ this is the effect of the print-out code
You do the DUP before EACH: so you are giving it a copy of the LIST item. Also, the code inside of the loop destroys the top item on the stack. So, your stack effect must look like this:
> : each: ( node -- next-node node true | false )
You said this however:
> The stack effect for EACH: ( -- item true | false )
That can't be true!
Is FMS open-source? Can I download the code so I can find out for myself what EACH: does? Your description is very confusing --- this doesn't jibe with the code that you are showing.
I think that an IS-A function would be pretty useful; I don't have that in my novice-package code. I doubt that I would want a HAS-A function (the foundation of duck-typing) as that is very complicated and inefficient. I may look at your FMS to get some ideas, and then write my own version for the novice-package (I would give you credit if my version takes any code from yours) --- I can't get code put into FLAG because that is Stephen Pelc's website and he only accepts code from Forth-200x supporters --- I can only put code into my own novice-package.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-15 06:17 -0400 |
| Message-ID | <57b196d0$0$297$14726298@news.sunsite.dk> |
| In reply to | #50114 |
On 8/14/16 9:55 PM, hughaguilar96@gmail.com wrote: > On Sunday, August 14, 2016 at 5:12:15 PM UTC-7, Doug Hoffman wrote: >> On 8/14/16 4:57 PM, hughaguilar96@gmail.com wrote: >>>>> Just guessing, I would expect that your EACH: is defined like this: >>>>> : each: ( node -- node true | false ) >>>>> dup 0<> \ -- node flag >>>>> dup 0= if nip then ; >> >> No, EACH: looks nothing like the above. >> The stack effect for EACH: ( -- item true | false ) >> EACH: is a message that is sent to a list or array object. >> The item it returns depends on the list, in the case of >> an object-list it returns an object. > > You are responding to a post that I deleted. How can you even find a > deleted post??? Why would you want to? Obviously, I deleted that post > because I had a mistake in it. For you to somehow obtain my deleted post > and quote the mistaken part, seems like a cheap shot. This is what I > said in the post that I didn't delete: Your post just appeared to my reader as all other posts do. I did nothing and had/have no way of knowing you tried to delete it. Sorry, no malicious intent. > You do the DUP before EACH: so you are giving it a copy of the LIST > item. Also, the code inside of the loop destroys the top item on the > stack. So, your stack effect must look like this: >> : each: ( node -- next-node node true | false ) > You said this however: >> The stack effect for EACH: ( -- item true | false ) > That can't be true! With many (most?) Forth object systems the methods never see the object as a passed in parameter. The object is removed from the stack by the system. Otherwise every method would have to explicitly do something with the object. With FMS a method never sees the object (it is placed in the value SELF actually), hence the stack effect I showed you. But external to the method definition it is always understood that a message send needs to be of the form <object> <message> on the stack. > Is FMS open-source? Yes. No restrictions whatsoever. > Can I download the code so I can find out for > myself what EACH: does? Yes. I already provided the link to the FLAG website. You can download it from there. EACH: is defined in file FMS-SILib.f for 3 or 4 different classes. For example class STRING+ has an EACH: for stepping through each character of a string. -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-15 17:37 -0700 |
| Message-ID | <a8b91da8-0c3a-42ea-8d31-74ab6126b767@googlegroups.com> |
| In reply to | #50147 |
On Monday, August 15, 2016 at 3:17:54 AM UTC-7, Doug Hoffman wrote: > On 8/14/16 9:55 PM, hughaguilar96@gmail.com wrote: > > You do the DUP before EACH: so you are giving it a copy of the LIST > > item. Also, the code inside of the loop destroys the top item on the > > stack. So, your stack effect must look like this: > >> : each: ( node -- next-node node true | false ) > > You said this however: > >> The stack effect for EACH: ( -- item true | false ) > > That can't be true! > > With many (most?) Forth object systems the methods never see the object > as a passed in parameter. The object is removed from the stack by the > system. Otherwise every method would have to explicitly do something > with the object. With FMS a method never sees the object (it is placed > in the value SELF actually), hence the stack effect I showed you. But > external to the method definition it is always understood that a message > send needs to be of the form <object> <message> on the stack. So EACH: has to examine the object that it is given to determine what type it is? Then it internally calls the version of itself appropriate to that type? This has to be done at run-time, because there is no information available at compile-time to indicate what type of object is being passed into the TEST function. Also, I don't understand where the next-node datum is being held. You have to keep track of where you are in the list, and this information has to be held somewhere. Just guessing, I would say that your LIST parameter given to TEST is a handle for the list, and the handle contains a field indicating the current node in the list that EACH: is using. When does this field get initialized though? Also, if there is a current-node field but no next-node field, then you can't clobber the current node or you won't be able to obtain the next node. In my system, it is okay to clobber the current node (change its .FORE field, such as when inserting it into another list) because the next node pointer has already been obtained . All in all, I find your FMS to be totally baffling. This is not going into the novice-package! I don't want to use code that I can't easily understand. Everything that I have in the novice-package so far is conceptually simple. All of this complication in FMS buys you polymorphism. I don't think that polymorphism is important though. I have EACH in LIST.4TH and I have <WALK WALK> and WALK in ASSOCIATION.4TH. I'm running out of though. If I later came up with a doubly-linked list called DLIST, I wouldn't be able to use EACH for it --- I would have to start prepending the class name to the method name --- in this case, DLIST-EACH would be it. For the most part, I don't think this is a problem. I don't foresee having more than a handful of different data-structures available. Most programs, even large programs, use only one data-structure. > EACH: is defined in file FMS-SILib.f for 3 or 4 different > classes. For example class STRING+ has an EACH: for stepping through > each character of a string. In STRING-STACK.4TH I have a function called STRING-WALK that executes an xt for every character of a string. Given polymorphism, I could have called this EACH just like in LIST.4TH. In ASSOCIATION.4TH I could have had EACH there too instead of WALK>. I don't think that polymorphism would have helped readability --- getting to use the word EACH for every data-structure isn't important to me --- I'm not going to shoulder the extreme complexity of your FMS just for this unimportant feature. Anyway, as fascinating as duck-typing may be, none of this has anything to do with quotations, which was the topic of the thread. Your MAP: is similar to my EACH that I have had for many years; it takes the xt of a colon word or :NONAME word. It does not have the capability of my |EACH that I recently wrote --- my |EACH takes an rquotation and when the rquotation executes it has access to the parent function's local variables --- that is what this thread is supposed to be about (of course, Anton's RfD has already gone to CfV so the thread is meaningless now anyway; it was a done deal from the very beginning).
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-17 06:16 -0400 |
| Message-ID | <57b4399a$0$293$14726298@news.sunsite.dk> |
| In reply to | #50160 |
On 8/15/16 8:37 PM, hughaguilar96@gmail.com wrote: > So EACH: has to examine the object that it is given to determine what > type it is? Type determination is done by the object system *before* any method is called. This is standard OOP behavior. EACH: is just a message and not the method (although we often use the two terms interchangeably, unfortunately). > Then it internally calls the version of itself > appropriate to that type? Using the vtable pointer from the object and the vtable offset from the message. Yes. Basically a '@ + @ execute' operation (a little more than that in practice). See the does> action of make-selector. > This has to be done at run-time, because > there is no information available at compile-time to indicate what > type of object is being passed into the TEST function. In the usual/general case yes. But this is at the programmer's discretion because early binding is available if wanted. I don't bother normally because late binding is very fast and more useful. > Also, I don't understand where the next-node datum is being held. > You have to keep track of where you are in the list, and this information > has to be held somewhere. Just guessing, I would say that your LIST > parameter given to TEST is a handle for the list, Yes. It's just an object (a list object in this case). > and the handle > contains a field indicating the current node in the list that EACH: is > using. When does this field get initialized though? When the object is created via the implicit init: constructor message. > Also, if there is a > current-node field but no next-node field, then you can't clobber the > current node or you won't be able to obtain the next node. That depends on the details of the way the list iterates. In the case of the lists I've shown iteration does not depend on information from the previous item, although it could if desired. > In my system, > it is okay to clobber the current node (change its .FORE field, such as > when inserting it into another list) because the next node pointer has > already been obtained . > > All in all, I find your FMS to be totally baffling. This is not going > into the novice-package! I don't want to use code that I can't > easily understand. Everything that I have in the novice-package so > far is conceptually simple. You should definitely stick with what you're most comfortable. Actually, FMS (OOP) isn't hard to understand. The code is all ANS Forth and all source is provided with a .pdf explanation file. The source is short and the object system compiles to <12k on VFX for OSX (without library classes). > All of this ... in FMS buys you polymorphism. It provides more than that, as do most Forth object extensions. Though FMS is unique in several ways, duck typing being just one. -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-17 19:58 -0700 |
| Message-ID | <9c246be6-41da-4c00-a322-cf8421343983@googlegroups.com> |
| In reply to | #50185 |
On Wednesday, August 17, 2016 at 3:17:01 AM UTC-7, Doug Hoffman wrote: > On 8/15/16 8:37 PM, hughaguilar96@gmail.com wrote: > > This has to be done at run-time, because > > there is no information available at compile-time to indicate what > > type of object is being passed into the TEST function. > > In the usual/general case yes. But this is at the programmer's > discretion because early binding is available if wanted. > I don't bother normally because late binding is very fast and more useful. I didn't see any declaration in your TEST function indicating what type the LIST parameter was. It had to be determined at run-time. In ANS-Forth you can't declare a type at the beginning of the function and have it work throughout the function (as done in StrongForth), so you would have to declare the type of each datum on the data-stack every time that it is used (prior to every message) --- I suspect you don't like to do that because it bloats out your source-code considerably --- there would be more housekeeping code than actual working code in most functions, making them difficult to read. > > Also, I don't understand where the next-node datum is being held. > > You have to keep track of where you are in the list, and this information > > has to be held somewhere. Just guessing, I would say that your LIST > > parameter given to TEST is a handle for the list, > > Yes. It's just an object (a list object in this case). > > > and the handle > > contains a field indicating the current node in the list that EACH: is > > using. When does this field get initialized though? > > When the object is created via the implicit init: constructor message. If you iterate through the object more than once, then it has to be initialized every time. > > Also, if there is a > > current-node field but no next-node field, then you can't clobber the > > current node or you won't be able to obtain the next node. > > That depends on the details of the way the list iterates. > In the case of the lists I've shown iteration does not depend on > information from the previous item, although it could if desired. I don't understand what you are talking about! You have to obtain the next-node pointer prior to running your code (in case the current node gets clobbered) and you have to hold this information somewhere --- I am still baffled as to where this information is being held or where it gets initialized. > > In my system, > > it is okay to clobber the current node (change its .FORE field, such as > > when inserting it into another list) because the next node pointer has > > already been obtained . > > > > All in all, I find your FMS to be totally baffling. This is not going > > into the novice-package! I don't want to use code that I can't > > easily understand. Everything that I have in the novice-package so > > far is conceptually simple. > > You should definitely stick with what you're most comfortable. Well, Stephen Pelc has endorsed your FMS by putting it in FLAG --- it is impossible for me to get any of my general-purpose code into FLAG --- the novice-package and FLAG are quite separate. I get the impression that things like your FMS were put into FLAG and endorsed by Stephen Pelc so he could say that ANS-Forth supports general-purpose data-structures --- nobody actually uses any of this though, partially because they are forbidden to do so by Elizabeth Rather, and partially because it is too complicated for them to understand (FMS is too complicated for me to understand) --- Stephen Pelc himself doesn't use general-purpose data-structures. > Actually, FMS (OOP) isn't hard to understand. The code is all ANS Forth > and all source is provided with a .pdf explanation file. The source is > short and the object system compiles to <12k on VFX for OSX (without > library classes). My OOP package that I just wrote is much shorter --- about 80 lines of heavily-commented source-code: https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE > > All of this ... in FMS buys you polymorphism. > > It provides more than that, as do most Forth object extensions. > Though FMS is unique in several ways, duck typing being just one. Well, I don't have any interest in duck-typing --- the HAS-A function is inherently inefficient because it is doing work at run-time --- this is work that could be done at compile-time with a little bit of planning ahead. I have never understood how a person can get into the situation of having an object and not knowing what methods are available for it --- the API should be documented --- why would the HAS-A function ever be needed?
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-18 07:52 -0400 |
| Message-ID | <57b5a169$0$299$14726298@news.sunsite.dk> |
| In reply to | #50196 |
On 8/17/16 10:58 PM, hughaguilar96@gmail.com wrote: > On Wednesday, August 17, 2016 at 3:17:01 AM UTC-7, Doug Hoffman wrote: >> On 8/15/16 8:37 PM, hughaguilar96@gmail.com wrote: >> ( list initialization occurs) When the object is created via the >> implicit init: constructor message. > > If you iterate through the object more than once, then it has to be > initialized every time. If one iterates all the way to the end of the list then the each: method re-initializes. If one interrupts the iteration but later resumes iteration picks up where it left off. This can be handy. One can manually reset the iteration at any time with the uneach: message. >>> Also, if there is a >>> current-node field but no next-node field, then you can't clobber the >>> current node or you won't be able to obtain the next node. >> >> That depends on the details of the way the list iterates. >> In the case of the lists I've shown iteration does not depend on >> information from the previous item, although it could if desired. > > I don't understand what you are talking about! If you want to know read the source for the each: definition in class 1-array in file FMS-SILib.f. The documentation for the classes in that file is poor. Though that file is provided primarily as examples of how to use FMS to define one's own classes. Still, I should work on the docs for it. -Doug
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-18 07:50 +0000 |
| Message-ID | <2016Aug18.095059@mips.complang.tuwien.ac.at> |
| In reply to | #50185 |
Doug Hoffman <glidedog@gmail.com> writes:
>On 8/15/16 8:37 PM, hughaguilar96@gmail.com wrote:
>
>> So EACH: has to examine the object that it is given to determine what
>> type it is?
>
>Type determination is done by the object system *before* any method is
>called. This is standard OOP behavior. EACH: is just a message and not
>the method (although we often use the two terms interchangeably,
>unfortunately).
Actually, in Smalltalk terminology, EACH: is a selector, and the
message is the selector plus the arguments (but not the receiving
object). A method is the code that is called when a message is sent
to an object; it is determined by the selector and the class of the
object.
Unfortunately, many other languages don't differentiate between method
and selector in their terminology.
- 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 | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-18 07:03 -0400 |
| Message-ID | <57b5960f$0$299$14726298@news.sunsite.dk> |
| In reply to | #50201 |
On 8/18/16 3:50 AM, Anton Ertl wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> Type determination is done by the object system *before* any method is
>> called. This is standard OOP behavior. EACH: is just a message and not
>> the method (although we often use the two terms interchangeably,
>> unfortunately).
>
> Actually, in Smalltalk terminology, EACH: is a selector, and the
> message is the selector plus the arguments (but not the receiving
> object).
Normally I would say that the terms 'message' and 'selector' are
synonymous. That difference is a finer point than is useful, IMO.
The following references use the term 'message':
http://www.cs.vu.nl/~eliens/oop/A.html
"Most important is the notion of object, which is something that acts in
response to messages (by executing a method procedure)."
http://tinyurl.com/h9x8jwm
"There is an important distinction between "methods" and "messages". A
method is a body of code, while a message is something that is sent."
Whereas the following defines terms as you have:
http://tinyurl.com/zoj9ktk
" - Selector: The name of a message
- Message: A selector together with actual parameter values"
But acknowledges inconsistent term use between 'method' and 'selector'.
> A method is the code that is called when a message is sent
> to an object; it is determined by the selector and the class of the
> object.
Yes. Though I might say the method is determined by the message and the
class of the receiving object.
-Doug
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-08-15 07:01 +0300 |
| Message-ID | <norequ$quc$1@dont-email.me> |
| In reply to | #50111 |
On 15/08/2016 03:12, Doug Hoffman wrote: ) invalid message send error detection > > 1) is always there > 2) can be turned on and off with a compile time switch > >> Duck-typing is done at run-time --- this can't be turned off. > > Correct. See 1) above. All this talk about 'duck-typing' sent me to wikipedia to figure out that you all are talking about dynamic type resolution. Here I thought it was another term for 'camel-case'... Just figured I'd mention that in 8th, you accomplish this in two ways: First, you can use the "l:" modifier word before an ambiguous word. For example, you can say "l: +" -- and then at run-time, the appropriate "+" will be used. Thus, a string could be concatenated or a number added using the same word. That is, of course, a silly example; in fact, "l:" has never been used in the 8th code anywhere. Second, you can use the word ">kind" to determine... the kind of the item on TOS. That word returns a number corresponding to the item's type, so you can then determine what to do. This is used quite often, as the penalty for determining an item's type is very small. Note that by default, "duck-typing" does not occur -- the types are determined at compile-time (interpret-time), mostly correctly. Now to Hugh: it has nothing at all to do with OOP. 8th has no OOP mechanism in particular to speak of.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-15 07:49 +0000 |
| Message-ID | <2016Aug15.094929@mips.complang.tuwien.ac.at> |
| In reply to | #50125 |
Ron Aaron <rambamist@gmail.com> writes:
>All this talk about 'duck-typing' sent me to wikipedia to figure out
>that you all are talking about dynamic type resolution.
Not quite.
Let's consider a drawing program: You define a class Circle with a
method draw, and a class Triangle with a method draw, and somewhere
you call draw, and you can pass a circle to it, or a triangle. That's
dynamic dispatch (dynamic type resolution), and every object-oriented
programming language supports that.
Now, in Java or C++, in order to do that, you have to define a common
parent class DrawObject of Circle and Triangle that also has a method
draw (or, in Java, alternatively an interface Drawable that both
Circle and Triangle implement and that has a method draw). These
languages have dynamic dispatch, but no duck typing.
In Smalltalk, you can just define Circle and Triangle, each with
method draw, without any requirement to define a common parent class
or interface with method draw. That's duck typing.
- 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 | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-08-15 11:48 +0300 |
| Message-ID | <norvks$3t7$1@dont-email.me> |
| In reply to | #50134 |
On 15/08/2016 10:49, Anton Ertl wrote: > Ron Aaron <rambamist@gmail.com> writes: >> All this talk about 'duck-typing' sent me to wikipedia to figure out >> that you all are talking about dynamic type resolution. > > Not quite. > > Let's consider a drawing program: You define a class Circle with a > method draw, and a class Triangle with a method draw, and somewhere > you call draw, and you can pass a circle to it, or a triangle. That's > dynamic dispatch (dynamic type resolution), and every object-oriented > programming language supports that. > > Now, in Java or C++, in order to do that, you have to define a common > parent class DrawObject of Circle and Triangle that also has a method > draw (or, in Java, alternatively an interface Drawable that both > Circle and Triangle implement and that has a method draw). These > languages have dynamic dispatch, but no duck typing. > > In Smalltalk, you can just define Circle and Triangle, each with > method draw, without any requirement to define a common parent class > or interface with method draw. That's duck typing. Ah, ok. You could emulate that in 8th with user-defined types, where you invoke a named "method" (which would just be a key pointing to a word) if it exists, but not if it doesn't. Unless you're really in a situation where you don't know the type you're going to get, however, it would be better to simply dispatch the correct corresponding method directly.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-15 09:53 +0000 |
| Subject | Duck Typing (was: 3rd RfD: Quotations) |
| Message-ID | <2016Aug15.115313@mips.complang.tuwien.ac.at> |
| In reply to | #50139 |
Ron Aaron <rambamist@gmail.com> writes:
>Unless you're really in a situation where you don't know the type you're
>going to get, however, it would be better to simply dispatch the correct
>corresponding method directly.
With duck typing, you are at least one step further: Not only do you
not need to know what method is bound at run-time to the method
selector (dynamic dispatch), you also do not need to know that a
method for a selector is going to be defined in a class that is not a
subclass of the one where you first define it (duck typing). If you
continue on the path to pure object-oriented languages where
everything is a method selector, in those languages you do not need to
know at the start that a particular selector is going to be used for
dynamic dispatch (pure OO).
- 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 | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-08-15 13:14 +0300 |
| Subject | Re: Duck Typing |
| Message-ID | <nos4mk$hst$1@dont-email.me> |
| In reply to | #50145 |
On 08/15/2016 12:53, Anton Ertl wrote: > With duck typing, you are at least one step further: Not only do you > not need to know what method is bound at run-time to the method > selector (dynamic dispatch), you also do not need to know that a > method for a selector is going to be defined in a class that is not a > subclass of the one where you first define it (duck typing). If you > continue on the path to pure object-oriented languages where > everything is a method selector, in those languages you do not need to > know at the start that a particular selector is going to be used for > dynamic dispatch (pure OO). Right. So something like the mechanism I mentioned will work well. Look up the name in the "object" you're given, and dispatch if it exists. I personally don't need that for anything I've ever written, but it could be useful.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-08-15 17:42 +0300 |
| Subject | Re: Duck Typing |
| Message-ID | <noskcs$5bt$1@dont-email.me> |
| In reply to | #50146 |
On 15/08/2016 13:14, Ron Aaron wrote: > Right. So something like the mechanism I mentioned will work well. > Look up the name in the "object" you're given, and dispatch if it exists. > > I personally don't need that for anything I've ever written, but it > could be useful. I found it amusing enough to implement a sample in 8th: http://8th-dev.com/forum/index.php/topic,1052.0.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-15 08:10 +0000 |
| Message-ID | <2016Aug15.101001@mips.complang.tuwien.ac.at> |
| In reply to | #50087 |
Doug Hoffman <glidedog@gmail.com> writes:
>On 8/14/16 10:10 AM, hughaguilar96@gmail.com wrote:
>> On Sunday, August 14, 2016 at 5:37:52 AM UTC-7, Doug Hoffman wrote:
>>> "Smalltalk-like duck typing. Any message can be sent to any object. If the message is not valid for that object then a "not understood" error occurs."
>>> another:
>>> "All message sends are by default dynamically resolved to the proper method at run time."
>>
>> Duck-typing is inefficient because you need to determine at run-time
>> whether a message will work for a particular object or not.
>
>Only during development. That check is turned off for final code.
You can implement duck typing with fast dispatch without checks and
get the not-understood action for the classes that don't understand
the message. The cost is that you need a slot for every (fast)
selector in every class, so for m classes and n fast selectors, you
need m*n cells for dispatch tables.
- 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 | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-15 05:47 -0400 |
| Message-ID | <57b18fce$0$297$14726298@news.sunsite.dk> |
| In reply to | #50136 |
On 8/15/16 4:10 AM, Anton Ertl wrote: > Doug Hoffman <glidedog@gmail.com> writes: >> On 8/14/16 10:10 AM, hughaguilar96@gmail.com wrote: >>> On Sunday, August 14, 2016 at 5:37:52 AM UTC-7, Doug Hoffman wrote: >>>> "Smalltalk-like duck typing. Any message can be sent to any object. If the message is not valid for that object then a "not understood" error occurs." >>>> another: >>>> "All message sends are by default dynamically resolved to the proper method at run time." >>> >>> Duck-typing is inefficient because you need to determine at run-time >>> whether a message will work for a particular object or not. >> >> Only during development. That check is turned off for final code. > > You can implement duck typing with fast dispatch without checks and > get the not-understood action for the classes that don't understand > the message. The cost is that you need a slot for every (fast) > selector in every class, so for m classes and n fast selectors, you > need m*n cells for dispatch tables. Yes. You're right. To minimize table sizes where possible FMS uses the check: it's simple to implement. The check is actually pretty fast and usually I just leave it on. Only in extreme cases I will feel the need to turn it off. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <alex@rivadpm.com> |
|---|---|
| Date | 2016-08-15 12:10 +0100 |
| Message-ID | <nos7vh$rn1$2@dont-email.me> |
| In reply to | #50136 |
On 15/08/16 09:10, Anton Ertl wrote: > Doug Hoffman <glidedog@gmail.com> writes: >> On 8/14/16 10:10 AM, hughaguilar96@gmail.com wrote: >>> On Sunday, August 14, 2016 at 5:37:52 AM UTC-7, Doug Hoffman wrote: >>>> "Smalltalk-like duck typing. Any message can be sent to any object. If the message is not valid for that object then a "not understood" error occurs." >>>> another: >>>> "All message sends are by default dynamically resolved to the proper method at run time." >>> >>> Duck-typing is inefficient because you need to determine at run-time >>> whether a message will work for a particular object or not. >> >> Only during development. That check is turned off for final code. > > You can implement duck typing with fast dispatch without checks and > get the not-understood action for the classes that don't understand > the message. The cost is that you need a slot for every (fast) > selector in every class, so for m classes and n fast selectors, you > need m*n cells for dispatch tables. > > - anton > For <dyn-object :method> we can create a method hash at compile time and do a hash table look up the method in the class at run time. This is the technique Win32Forth uses*; the class methods are in fact word lists like vocabularies built by the class. Caching the method pointer with the object & method hash pair as a key should improve performance. The overhead in space for each class is h+m cells where h is the hash table size and m is the number of methods for this class. I tried building an object system loosely based on Ian Piumarta's work. It is the ultimate in duck typing, since there are no classes, just objects; and objects can have methods (which are actually objects) dynamically added and subtracted at run time. My conclusions were that Forth is not the language in which to be doing this; it is hell to debug. http://piumarta.com/software/cola/objmodel2.pdf As to performance, it was quite acceptable; my laptop (an i7) running on a single core with a native code Forth could do in excess of a million method dispatches a second. Caching definitely helped (at least, it did in synthetic benchmarks, where it improved performance by a factor of 10 or so). I wrote some notes on the subject and posted them here in 2011. How time flies. *(The original Win32Forth hash was quite weak, and the methods named GETPOINT and SETPOINT hashed to the same value. There are downsides to these kind of mappings.) -- Alex
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web