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 | 6 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 10 of 10 — ← Prev page 1 … 8 9 [10]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-08-18 08:38 -0500 |
| Message-ID | <uNydnWmvK4nHJyjKnZ2dnUU7-QOdnZ2d@supernews.com> |
| In reply to | #50148 |
Alex McDonald <alex@rivadpm.com> wrote: > > 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 Hmm, interesting. What makes it hard to debug? Lack of tools or something else? It's very pleasingly simple, and has the pleasing property that it would be very easy to extend. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <alex@rivadpm.com> |
|---|---|
| Date | 2016-08-19 20:44 +0100 |
| Subject | Piumarta object model (was Re: 3rd RfD: Quotations |
| Message-ID | <np7nid$fof$1@dont-email.me> |
| In reply to | #50211 |
On 18/08/16 14:38, Andrew Haley wrote: > Alex McDonald <alex@rivadpm.com> wrote: >> >> 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 > > Hmm, interesting. What makes it hard to debug? Lack of tools or > something else? It's very pleasingly simple, and has the pleasing > property that it would be very easy to extend. > > Andrew. > Well, it's a number of years now since I did anything serious with it. But here are a number of observations. I would need to retrieve my notes for 100% accuracy, which I won't be doing that soon; I'm in the process of moving house. Interning symbol strings is messy, as is searching them. I used a wordlist as an alternative. LOOKUP is recursive, and I attempted to get rid of this by tail recursion. One recursion down, but... The code between SEND and BIND is heavily recursive and there's not much that can be done about that; it's key to the process. In summary, the big problems relate to recursion, which is quite difficult to debug after a crash or on stack exhaustion. I did get it working after a fashion, but there were a number of mystifying anomalies with finding methods and searching parent objects. I believe the C code Piumarta supplies (at the foot of the paper) doesn't quite match the metacode description. I don't know if I'm right here, since C with pointers and types (and boy, does it have pointers and types) is not my specialty. I wrote the Forth from the metacode. I think you & I discussed this before, in late 2011 or 2012, here on CLF. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <alex@rivadpm.com> |
|---|---|
| Date | 2016-08-19 20:58 +0100 |
| Subject | Re: Piumarta object model (was Re: 3rd RfD: Quotations |
| Message-ID | <np7occ$igu$2@dont-email.me> |
| In reply to | #50255 |
On 19/08/16 20:44, Alex McDonald wrote: > On 18/08/16 14:38, Andrew Haley wrote: >> Alex McDonald <alex@rivadpm.com> wrote: >>> >>> 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 >> >> Hmm, interesting. What makes it hard to debug? Lack of tools or >> something else? It's very pleasingly simple, and has the pleasing >> property that it would be very easy to extend. >> >> Andrew. >> > > Well, it's a number of years now since I did anything serious with it. > But here are a number of observations. I would need to retrieve my notes > for 100% accuracy, which I won't be doing that soon; I'm in the process > of moving house. > > Interning symbol strings is messy, as is searching them. I used a > wordlist as an alternative. > > LOOKUP is recursive, and I attempted to get rid of this by tail > recursion. One recursion down, but... > > The code between SEND and BIND is heavily recursive and there's not much > that can be done about that; it's key to the process. > > In summary, the big problems relate to recursion, which is quite > difficult to debug after a crash or on stack exhaustion. I did get it > working after a fashion, but there were a number of mystifying anomalies > with finding methods and searching parent objects. I believe the C code > Piumarta supplies (at the foot of the paper) doesn't quite match the > metacode description. I don't know if I'm right here, since C with > pointers and types (and boy, does it have pointers and types) is not my > specialty. I wrote the Forth from the metacode. > > I think you & I discussed this before, in late 2011 or 2012, here on CLF. > Here: https://groups.google.com/forum/message/raw?msg=comp.lang.forth/F5PcpRJMFaU/2FP0U-y3uvEJ You commented on the use of a wordlist for the symbol interning. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-08-15 07:04 -0700 |
| Message-ID | <f03d2c19-9b5d-49f6-9b16-fd310d5bb6d9@googlegroups.com> |
| In reply to | #50136 |
Le lundi 15 août 2016 10:19:45 UTC+2, Anton Ertl a écrit : > 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/ This is not quite how duck typing is implemented in Oforth. In Oforth, virtual tables (slots) are handled by the methods (what you call the selectors) themselves, not by the classes. Those VT are adjusted dynamically, at runtime. So : 1) If a method is not used by the program, no memory is allocated for its VT. 2) You can add an implementation of a method for a particular class when you want (and not only during the class declaration). This is important to be able to do this in oforth. 3) As you create (and adjust) the VT to the size needed according to the objects that call the method, VT have only the needed size (not always a m classes size). All methods have this behavior. There is no other alternative. Franck
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 07:25 -0700 |
| Message-ID | <15a27c89-4623-40ba-94b7-0e8a2832fcd4@googlegroups.com> |
| In reply to | #50081 |
On Sunday, August 14, 2016 at 5:37:52 AM UTC-7, Doug Hoffman wrote:
> On 8/13/16 11:24 PM, hughaguilar96@gmail.com wrote:
>
> > Duck-typing ... You have
> > to send the message to the object as a string, and this string is looked
> > up in the method-table for that object --- this is done at run-time
> > every time the method is called ...
>
> No. Wrong assumption.
>
> Also, if one is using VFX then the message send can be optimized to just
> two instructions. This is fast.
>
> : foo each: ; \ each: is a message
> see foo
> FOO
> ( 0008A110 8B13 ) MOV EDX, 0 [EBX]
> ( 0008A112 FF5214 ) CALL [EDX+14]
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:
> "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.
In your example you used IS-A to determine if the object was of a specific type, and then you executed a method in the object --- this is not duck-typing though, which is done with a HAS-A function (significantly slower than the IS-A function).
You are right that the hottie-counting program is not necessarily going to be slow (I was wrong to assume that the message was a string like in OpenForth) --- so long as you avoid using HAS-A (as you did) then your program will be reasonably efficient --- so long as you avoid the duck-typing aspect of FMS then you should get reasonably efficient code (but the package is called "Forth Meets Smalltalk" which implies that the duck-typing aspect is the whole point of the package).
Your program is pretty similar to my MACRO-TEST version. You have this:
begin
dup each:
while
...
repeat
This is comparable to my macros:
[each
...
]each
I think that the use of macros improves readability a lot as compared to manually typing out the BEGIN WHILE REPEAT code for your loop.
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.
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 next node and 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 how [EACH and ]EACH are defined in the novice package:
macro: each[
begin dup while
dup .fore @ >r ;
macro: ]each
r> repeat drop ;
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 ;
That not only lacks all of the features of my [EACH and ]EACH but it is also less efficient (it is doing the conditional twice).
All in all, I think that I'm way ahead of FMS or any other Forth OOP package --- I've never seen any Forth OOP system that compares well to my novice-package, and I don't expect that I ever will.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 07:19 -0700 |
| Message-ID | <2d84ec86-adce-455d-8c06-a903a7bbfb80@googlegroups.com> |
| In reply to | #50030 |
On Sunday, August 14, 2016 at 5:37:52 AM UTC-7, Doug Hoffman wrote:
> On 8/13/16 11:24 PM, hughaguilar96@gmail.com wrote:
>
> > Duck-typing ... You have
> > to send the message to the object as a string, and this string is looked
> > up in the method-table for that object --- this is done at run-time
> > every time the method is called ...
>
> No. Wrong assumption.
>
> Also, if one is using VFX then the message send can be optimized to just
> two instructions. This is fast.
>
> : foo each: ; \ each: is a message
> see foo
> FOO
> ( 0008A110 8B13 ) MOV EDX, 0 [EBX]
> ( 0008A112 FF5214 ) CALL [EDX+14]
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:
> "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.
In your example you used IS-A to determine if the object was of a specific type, and then you executed a method in the object --- this is not duck-typing though, which is done with a HAS-A function (significantly slower than the IS-A function).
You are right that the hottie-counting program is not necessarily going to be slow (I was wrong to assume that the message was a string like in OpenForth) --- so long as you avoid using HAS-A (as you did) then your program will be reasonably efficient --- so long as you avoid the duck-typing aspect of FMS then you should get reasonably efficient code (but the package is called "Forth Meets Smalltalk" which implies that the duck-typing aspect is the whole point of the package).
Your program is pretty similar to my MACRO-TEST version. You have this:
begin
dup each:
while
...
repeat
This is comparable to my macros:
[each
...
]each
I think that the use of macros improves readability a lot as compared to manually typing out the BEGIN WHILE REPEAT code for your loop.
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.
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 next node and 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 how [EACH and ]EACH are defined in the novice package:
macro: each[
begin dup while
dup .fore @ >r ;
macro: ]each
r> repeat drop ;
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
else
drop false
then ;
That not only lacks all of the features of my [EACH and ]EACH but it is also less efficient (it is doing the conditional twice).
All in all, I think that I'm way ahead of FMS or any other Forth OOP package --- I've never seen any Forth OOP system that compares well to my novice-package, and I don't expect that I ever will.
[toc] | [prev] | [standalone]
Page 10 of 10 — ← Prev page 1 … 8 9 [10]
Back to top | Article view | comp.lang.forth
csiph-web