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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | franck.bensusan@gmail.com |
|---|---|
| Date | 2016-07-10 13:21 -0700 |
| Message-ID | <759cad41-e5cb-4567-b1f6-4f5ec1eb9ad7@googlegroups.com> |
| In reply to | #49017 |
Le dimanche 10 juillet 2016 21:51:09 UTC+2, JennyB a écrit : > The simple Forth version of course consumes code space each time it is used, but I have used it (without knowing it was called curry) to initialise an action table with a particular class of xt without having to invent a name for each. This is a subject where an implementation using a closure is much more powerfull.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-10 13:23 -0700 |
| Message-ID | <e78ecee0-4515-4434-bfc6-c69bd8a00d18@googlegroups.com> |
| In reply to | #49016 |
On Sunday, July 10, 2016 at 1:04:13 PM UTC-5, hughag...@gmail.com wrote:
>
> Factor had curry. It was never clear to me what this would be used for. Can you explain some practical purpose for this?
Mostly, there isn't a practical purpose to it. It fills a design
niche and makes sense for some languages. To show that:
erlang(A) -> A+1.
erlang(A, B) -> A + B.
erlang/1 and erlang/2 are completely different functions. That they
share 'erlang' in their name is meaningless. The arity - the number
of arguments - is part of the name. Because Erlang functions all
have definite numbers of arguments, you can't have a function that
takes a variable number of arguments (in Erlang a list or like would
be passed instead, as a single argument); because creating erlang/2
does not imply anything about erlang/1 (or erlang/N for other
arities), this is an error:
erlang(A, B) -> A + B.
foo() ->
....,
F = erlang(1), % error: *what* erlang/1??
F(2).
Meanwhile,
sub perl { shift + 1 }
perl() takes an arbitrary number of arguments, picks the first
argument out of them, and returns that plus one. It's an error to
define another 'perl' and it couldn't take different arguments
anyway. If you pass a function an insufficient number of arguments,
that function just receives undef as those parameters.
Meanwhile... Haskell would be a better example but I'm still trying
to forget what knowledge I retain of that contemptible language, so
please accept
:- func mercury(int, int) = int.
mercury(A, B) = A + B.
: pred foo(int::out) is det.
foo(X) :-
X = F(2), % the second argumment is supplied here
F = mercury(1). % the first argument is supplied here
Predicates and functions in Mercury have definite numbers of
arguments and (unless you explicitly define a contradiction of this)
curry when given partial arguments. Mercury is a bit weird for
allowing this though:
: func mercury(int) = int.
mercury(A) = "j/k no curry for you".
% but you could've done it otherwise -- actually you can still do it
% if you had a mercury/2 with different types in another imported
% another module
When your functions auto-curry, you can pretend that you really only
have one-argument functions, like in math.
foo(A, B, C) is really foo(A)(B)(C), or (((foo A) B) C), or
X1 = foo(A), % X1 is a function
X2 = X1(B), % X2 is a function
X3 = X2(C). % X3 is whatever foo(A, B, C) returns
Which grants you... nothing. But there it is. Programming
languages are rich and varied. This is some of that variation.
And for the most part it's contradictory variation. Taking one path
bars you from taking the others. Mercury pays a price to flaunt
that to the extent it does.
Meanwhile, the actual utility of currying is this:
1. I want to call a function across every member of this list
2. but the function is : super-boring 3 * ;
3. so rather than name it, wouldn't it be nice if I could just
supply * with a single argument, and get an anonymous function
that I can then run across this list?
4. oh I have currying so I can do that
3 ' * curry: 3*
' 3* my-list do-list \ yay!
Of course, if creating arbitary functions is pretty terse already,
there's no point.
[: 3 * ;] my-list do-list \ wow so much better in every way!
And if you want to supply an argument to a function that is anything
other than the very first argument, but still want to curry, then
you need to have a bunch of what are basically stack manipulation
words.
\ haskell literally has this function
: flip ( xt -- xt )
>r :noname POSTPONE swap r> compile, POSPTONE ; ;
' / flip constant reverse-/
\ reminder: the numerator is the second argument that / pops off
\ the stack
21 ' reverse-/ curry: 21/
' 21/ my-list do-list \ y-yaaaaay....
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-28 16:56 +0000 |
| Message-ID | <2016Jul28.185644@mips.complang.tuwien.ac.at> |
| In reply to | #48645 |
RfD: Quotations
---------------
Change history
--------------
28Jul2015 Alex McDonald v1 initial draft
04Aug2015 Alex McDonald v2 update
added & extended "Rationale", "Discussion"
formalised "Specification"
corrected "Implementation"
added "References"
01Jul2016 Anton Ertl v3
various non-substantive changes throughout
removed revised definition of RECURSE
revised the stack effect to have quotation-sys colon-sys
revised the specification wording
added tests
28Jul2016 Anton Ertl v4
";" and ";CODE" in quotations are now ambiguous (v3 ToDo result)
Added q6 test (please try it!)
minor changes
Quotations
==========
The essence of quotations is to provide nested colon definitions,
in which the inner definition(s) are nameless. The expression
: foo ... [: some words ;] ... ;
is equivalent to
:noname some words ; Constant #temp#
: foo ... #temp# ... ;
A simple quotation is an anonymous colon definition that is defined
inside a colon definition or quotation.
Rationale
---------
There is no situation where quotations cannot be implemented by
existing Forth words. Specifcially, :NONAME and : provide all the
features proposed for quotations. Their advantage is as a syntactic
"sugar" that permits a nameless definition in close proximity to its
use; and that it avoids generating one-use names only for the purpose
of refering to the definition inside another word.
One example use of quotations is to provide a solution to the use
of CATCH in a form close to other languages' TRY ... EXCEPT
blocks.
: hex. ( u -- )
base @ >r
[: hex u. ;] catch
r> base ! throw ;
The advantage of using CATCH here is that the BASE is restored even if
there is an exception (e.g., a user interrupt) during the "U.".
Moreover, return-address manipulation has often been used as a way to
split a definition into several parts, e.g,:
: foo bar list> bla blub ;
where LIST> is a return-address manipulating word and executes the BLA
BLUB part of the word possibly several times. This demonstrates that
introducing a helper definition is unattractive to these programmers;
with quotations this code could be written without helper word as
: foo bar [: bla blub ;] map-list ;
The advantages of this variant are: 1) Implementating quotations puts
less restrictions on the Forth system than implementing manipulable
return-addresses (which would restrict tail-call elimination and
inlining). 2) It is immediately visible to the reader that there is a
separate definition containing BLA BLUB.
Experience
----------
Under the term "Phrases", quotations have been in MacForth since at
least 1987. They are documented in the infamous "missing chapter" of
the MacForth manual.
Implementations exist in (at least) VFX, Gforth and iForth, and in the
iForth case appear to have some significant use and history. The
Gforth development version from 2016-06-28 contains 70 occurences of
";]".
Interactions
------------
Quotations change the "current definition" that a number of words (in
particular, RECURSE, DOES> and locals) refer to, so we have to look at
the interactions of these words and locals.
In these interactions there is a conflict between interface simplicity
and implementation simplicity. Disallowing all combinations of
quotations and these words would give most freedom to implementors to
choose the simplest implementation, but it would make for an interface
full of blind alleys: If you choose one feature, you cannot choose any
of the others; and if you need another feature, you have to back out
of using the first one. Moreover, all these restrictions would have
to be specified in the standard.
This is not desirable, so here we propose to make all these words work
for quotations as well as they work for standalone definitions; this
is relatively cheap to implement.
RECURSE
RECURSE inside a quotation calls the quotation directly surrounding
the RECURSE, not the containing colon definition.
DOES>
A DOES> part inside a quotation ends with the terminating ";]"
Using DOES> is actually a useful example of using quotations. E.g.,
<https://www.complang.tuwien.ac.at/forth/struct.fs> contains two
helper words (DOFIELD and DOZEROFIELD) in the following code:
: dofield ( -- )
does> ( name execution: addr1 -- addr2 )
@ + ;
: dozerofield ( -- )
immediate
does> ( name execution: -- )
drop ;
: field ( align1 offset1 align size "name" -- align2 offset2 )
\ name execution: addr1 -- addr2
2 pick >r \ this uglyness is just for optimizing with dozerofield
create-field
r> if \ offset<>0
dofield
else
dozerofield
then ;
Quotations allow to write this more compactly as:
: field ( align1 offset1 align size "name" -- align2 offset2 )
\ name execution: addr1 -- addr2
2 pick >r \ this uglyness is just for optimizing with dozerofield
create-field
r> if \ offset<>0
[: does> ( addr1 -- addr2 ) @ + ;]
else
immediate [: does> ( -- ) drop ;]
then
execute ;
The second RfD proposed to allow RECURSE after DOES> in general
(currently it is ambiguous), but this is not common practice yet, so
the present version removed this part of the proposal in order to
focus on the quotations proper.
Locals
A quotation may not be able to access the locals of the outer word
because it has no knowledge of when it might be executed and hence
whether outer locals are still alive. It does permit defining and
accessing its own locals. Note that this means that both the
quotation and the containing definition may define locals.
: foo ... [: {: a b :} a b + ;] ... ; \ unambiguous
: bar {: a b :} ... [: a b + ;] ... ; \ ambiguous
: bla {: a ;} ... [: {: b ;} ... b ... ;] ... a ... ; \ unambiguous
The present proposal does not propose that a quotation can access the
locals of a containing definition, because the implementation would be
relatively complex, impose a run-time overhead, and the lifetime of
the locals would be restricted (unless we are willing to accept
further complexity). While there are a number of people who are very
keen to have such a feature, it is not clear how much it would be
used. System implementors are encouraged to provide support for
accessing outer locals on an experimental basis so that programmers
can explore the usefulness of this feature, possibly resulting in a
proposal for this feature in the future.
Syntax
------
The following notations have been seen in the wild, oldest first.
:| ... |;
:[ ... ]:
[: ... ;]
The notation [: ;] appears to have popular support.
Specification
-------------
New system-compilation type quotation-sys with an
implementation-dependent size on the stack. This type contains the
data that needs to be saved for the enclosing colon definition and
restored after the end of the quotation. [Note: we use it in
combination with colon-sys, because DOES> uses colon-sys during
compilation.]
[: bracket-colon
Interpretation: Interpretation semantics for this word are undefined.
Compilation: ( -- quotation-sys colon-sys )
suspends compiling to the current definition, starts a new nested
definition with execution token xt, and compilation continues with
this nested definition. Locals may be defined in the nested
definition. An ambiguous condition exists if a name is used that
satisfies the following constraints: 1) It is not the name of a
currently visible local of the current quotation. 2) It is the name
of a local that was visible right before the start of the present
quotation or any of the containing quotations.
;] semi-bracket
Interpretation: Interpretation semantics for this word are undefined.
Compilation: ( c: quotation-sys colon-sys -- )
Ends the current nested definition, and resumes compilation to the
previous (containing) current definition. It appends the following
run-time to the (containing) current definition:
run-time: ( -- xt )
xt is the execution token of the nested definition.
Add the following ambiguous condition to ";" and ";CODE":
An ambiguous condition exists if the compilation semantics of ";" or
";CODE" are performed inside a quotation.
Implementation
--------------
It is not possible to define quotations in ISO Forth. The following
is an outline definition, where SAVE-DEFINITION-STATE and RESTORE-
DEFINITION-STATE require carnal knowledge of the system and are left
to the implementor.
: [: ( c: -- quotation-sys colon-sys )
postpone ahead save-definition-state :noname ; immediate
: ;] ( c: quotation-sys colon-sys -- ) ( s: -- xt )
postpone ; >r restore-definition-state
postpone then r> postpone literal ; immediate
Compliance Tests
----------------
\ works on Gforth:
T{ : q1 [: 1 ;] ; q1 execute -> 1 }T
T{ : q2 [: [: 2 ;] ;] ; q2 execute execute -> 2 }T
T{ : q3 {: a :} [: {: a b :} b a ;] ; 1 2 3 q3 execute -> 2 1 }T
T{ : q4 [: dup if dup 1- recurse then ;] ; 3 q4 execute .s -> 3 2 1 0 }T
T{ : q5 [: does> drop 4 ;] 5 swap ; create x q5 execute x -> 5 4 }T
T{ : q6 {: a :} [: {: a b :} b a ;] a 1+ ; 1 2 q6 swap execute -> 3 1 }T
References
----------
Stephen Pelc wrote this; see
http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html
I (Alex McDonald) have taken it and modified it as a proposed RfD,
and have removed the discussion of closures. http://www.forth200x.org/
I (Anton Ertl) have taken it and revised it.
The following notes on quotations and closures incorporate material
from several people, including Anton Ertl, Andrew Haley, Marcel
Hendrix, Ward Mcfarland, Bernd Paysan, and Elizabeth Rather. If you
have been left out and want acknowledgement, please let me know.
Additional contributors: Gerry Jackson and others.
[Note]
The phrase "ambiguous condition" has a specific meaning in Forth
standards. An ambiguous condition is "a circumstance for which this
standard does not prescribe a specific behavior". The RfD process
also states: "If you want to leave something open to the system
implementor, make that explicit, e.g., by making it an ambiguous
condition."
- 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 | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-28 16:29 -0700 |
| Message-ID | <c869d82c-d74c-4b65-8a52-36e5d3ad9e7b@googlegroups.com> |
| In reply to | #49618 |
On Thursday, July 28, 2016 at 9:59:12 AM UTC-7, Anton Ertl wrote:
> RfD: Quotations
> ---------------
>
> Change history
> --------------
> 28Jul2015 Alex McDonald v1 initial draft
> 04Aug2015 Alex McDonald v2 update
> added & extended "Rationale", "Discussion"
> formalised "Specification"
> corrected "Implementation"
> added "References"
> 01Jul2016 Anton Ertl v3
> various non-substantive changes throughout
> removed revised definition of RECURSE
> revised the stack effect to have quotation-sys colon-sys
> revised the specification wording
> added tests
> 28Jul2016 Anton Ertl v4
> ";" and ";CODE" in quotations are now ambiguous (v3 ToDo result)
> Added q6 test (please try it!)
> minor changes
>
>
> Quotations
> ==========
>
> The essence of quotations is to provide nested colon definitions,
> in which the inner definition(s) are nameless. The expression
>
> : foo ... [: some words ;] ... ;
>
> is equivalent to
>
> :noname some words ; Constant #temp#
> : foo ... #temp# ... ;
>
> A simple quotation is an anonymous colon definition that is defined
> inside a colon definition or quotation.
>
> Rationale
> ---------
>
> There is no situation where quotations cannot be implemented by
> existing Forth words. Specifcially, :NONAME and : provide all the
> features proposed for quotations. Their advantage is as a syntactic
> "sugar" that permits a nameless definition in close proximity to its
> use; and that it avoids generating one-use names only for the purpose
> of refering to the definition inside another word.
>
> One example use of quotations is to provide a solution to the use
> of CATCH in a form close to other languages' TRY ... EXCEPT
> blocks.
>
> : hex. ( u -- )
> base @ >r
> [: hex u. ;] catch
> r> base ! throw ;
>
> The advantage of using CATCH here is that the BASE is restored even if
> there is an exception (e.g., a user interrupt) during the "U.".
>
> Moreover, return-address manipulation has often been used as a way to
> split a definition into several parts, e.g,:
>
> : foo bar list> bla blub ;
>
> where LIST> is a return-address manipulating word and executes the BLA
> BLUB part of the word possibly several times. This demonstrates that
> introducing a helper definition is unattractive to these programmers;
> with quotations this code could be written without helper word as
>
> : foo bar [: bla blub ;] map-list ;
>
> The advantages of this variant are: 1) Implementating quotations puts
> less restrictions on the Forth system than implementing manipulable
> return-addresses (which would restrict tail-call elimination and
> inlining). 2) It is immediately visible to the reader that there is a
> separate definition containing BLA BLUB.
>
> Experience
> ----------
>
> Under the term "Phrases", quotations have been in MacForth since at
> least 1987. They are documented in the infamous "missing chapter" of
> the MacForth manual.
>
> Implementations exist in (at least) VFX, Gforth and iForth, and in the
> iForth case appear to have some significant use and history. The
> Gforth development version from 2016-06-28 contains 70 occurences of
> ";]".
>
> Interactions
> ------------
>
> Quotations change the "current definition" that a number of words (in
> particular, RECURSE, DOES> and locals) refer to, so we have to look at
> the interactions of these words and locals.
>
> In these interactions there is a conflict between interface simplicity
> and implementation simplicity. Disallowing all combinations of
> quotations and these words would give most freedom to implementors to
> choose the simplest implementation, but it would make for an interface
> full of blind alleys: If you choose one feature, you cannot choose any
> of the others; and if you need another feature, you have to back out
> of using the first one. Moreover, all these restrictions would have
> to be specified in the standard.
>
> This is not desirable, so here we propose to make all these words work
> for quotations as well as they work for standalone definitions; this
> is relatively cheap to implement.
>
>
> RECURSE
>
> RECURSE inside a quotation calls the quotation directly surrounding
> the RECURSE, not the containing colon definition.
>
> DOES>
>
> A DOES> part inside a quotation ends with the terminating ";]"
>
> Using DOES> is actually a useful example of using quotations. E.g.,
> <https://www.complang.tuwien.ac.at/forth/struct.fs> contains two
> helper words (DOFIELD and DOZEROFIELD) in the following code:
>
> : dofield ( -- )
> does> ( name execution: addr1 -- addr2 )
> @ + ;
>
> : dozerofield ( -- )
> immediate
> does> ( name execution: -- )
> drop ;
>
> : field ( align1 offset1 align size "name" -- align2 offset2 )
> \ name execution: addr1 -- addr2
> 2 pick >r \ this uglyness is just for optimizing with dozerofield
> create-field
> r> if \ offset<>0
> dofield
> else
> dozerofield
> then ;
>
> Quotations allow to write this more compactly as:
>
> : field ( align1 offset1 align size "name" -- align2 offset2 )
> \ name execution: addr1 -- addr2
> 2 pick >r \ this uglyness is just for optimizing with dozerofield
> create-field
> r> if \ offset<>0
> [: does> ( addr1 -- addr2 ) @ + ;]
> else
> immediate [: does> ( -- ) drop ;]
> then
> execute ;
>
> The second RfD proposed to allow RECURSE after DOES> in general
> (currently it is ambiguous), but this is not common practice yet, so
> the present version removed this part of the proposal in order to
> focus on the quotations proper.
>
> Locals
>
> A quotation may not be able to access the locals of the outer word
> because it has no knowledge of when it might be executed and hence
> whether outer locals are still alive. It does permit defining and
> accessing its own locals. Note that this means that both the
> quotation and the containing definition may define locals.
>
> : foo ... [: {: a b :} a b + ;] ... ; \ unambiguous
> : bar {: a b :} ... [: a b + ;] ... ; \ ambiguous
> : bla {: a ;} ... [: {: b ;} ... b ... ;] ... a ... ; \ unambiguous
>
> The present proposal does not propose that a quotation can access the
> locals of a containing definition, because the implementation would be
> relatively complex, impose a run-time overhead, and the lifetime of
> the locals would be restricted (unless we are willing to accept
> further complexity). While there are a number of people who are very
> keen to have such a feature, it is not clear how much it would be
> used. System implementors are encouraged to provide support for
> accessing outer locals on an experimental basis so that programmers
> can explore the usefulness of this feature, possibly resulting in a
> proposal for this feature in the future.
>
>
> Syntax
> ------
>
> The following notations have been seen in the wild, oldest first.
> :| ... |;
> :[ ... ]:
> [: ... ;]
>
> The notation [: ;] appears to have popular support.
>
>
> Specification
> -------------
>
> New system-compilation type quotation-sys with an
> implementation-dependent size on the stack. This type contains the
> data that needs to be saved for the enclosing colon definition and
> restored after the end of the quotation. [Note: we use it in
> combination with colon-sys, because DOES> uses colon-sys during
> compilation.]
>
> [: bracket-colon
> Interpretation: Interpretation semantics for this word are undefined.
>
> Compilation: ( -- quotation-sys colon-sys )
>
> suspends compiling to the current definition, starts a new nested
> definition with execution token xt, and compilation continues with
> this nested definition. Locals may be defined in the nested
> definition. An ambiguous condition exists if a name is used that
> satisfies the following constraints: 1) It is not the name of a
> currently visible local of the current quotation. 2) It is the name
> of a local that was visible right before the start of the present
> quotation or any of the containing quotations.
>
> ;] semi-bracket
> Interpretation: Interpretation semantics for this word are undefined.
>
> Compilation: ( c: quotation-sys colon-sys -- )
>
> Ends the current nested definition, and resumes compilation to the
> previous (containing) current definition. It appends the following
> run-time to the (containing) current definition:
>
> run-time: ( -- xt )
>
> xt is the execution token of the nested definition.
>
> Add the following ambiguous condition to ";" and ";CODE":
>
> An ambiguous condition exists if the compilation semantics of ";" or
> ";CODE" are performed inside a quotation.
>
>
> Implementation
> --------------
>
> It is not possible to define quotations in ISO Forth. The following
> is an outline definition, where SAVE-DEFINITION-STATE and RESTORE-
> DEFINITION-STATE require carnal knowledge of the system and are left
> to the implementor.
>
> : [: ( c: -- quotation-sys colon-sys )
> postpone ahead save-definition-state :noname ; immediate
> : ;] ( c: quotation-sys colon-sys -- ) ( s: -- xt )
> postpone ; >r restore-definition-state
> postpone then r> postpone literal ; immediate
>
>
> Compliance Tests
> ----------------
>
> \ works on Gforth:
>
> T{ : q1 [: 1 ;] ; q1 execute -> 1 }T
> T{ : q2 [: [: 2 ;] ;] ; q2 execute execute -> 2 }T
> T{ : q3 {: a :} [: {: a b :} b a ;] ; 1 2 3 q3 execute -> 2 1 }T
> T{ : q4 [: dup if dup 1- recurse then ;] ; 3 q4 execute .s -> 3 2 1 0 }T
> T{ : q5 [: does> drop 4 ;] 5 swap ; create x q5 execute x -> 5 4 }T
> T{ : q6 {: a :} [: {: a b :} b a ;] a 1+ ; 1 2 q6 swap execute -> 3 1 }T
>
>
> References
> ----------
>
> Stephen Pelc wrote this; see
>
> http://newsgroups.derkeiler.com/Archive/Comp/comp.lang.forth/2012-07/msg00791.html
>
> I (Alex McDonald) have taken it and modified it as a proposed RfD,
> and have removed the discussion of closures. http://www.forth200x.org/
>
> I (Anton Ertl) have taken it and revised it.
>
> The following notes on quotations and closures incorporate material
> from several people, including Anton Ertl, Andrew Haley, Marcel
> Hendrix, Ward Mcfarland, Bernd Paysan, and Elizabeth Rather. If you
> have been left out and want acknowledgement, please let me know.
>
> Additional contributors: Gerry Jackson and others.
>
> [Note]
> The phrase "ambiguous condition" has a specific meaning in Forth
> standards. An ambiguous condition is "a circumstance for which this
> standard does not prescribe a specific behavior". The RfD process
> also states: "If you want to leave something open to the system
> implementor, make that explicit, e.g., by making it an ambiguous
> condition."
>
> - 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/
Thank you for removing my name as a contributor! That was a pretty sleazy business, trying to claim that I supported the Paysan-faked quotations.
Anyway, since I now have |EACH available in LIST.4TH I went ahead and compiled my hottie-counting program. I modified it slightly so that it would inherit from SEQ rather than LIST which simplifies it slightly. Here is the program:
\ This needs NOVICE.4TH and LIST.4TH loaded.
\ This demonstrates how rquotations can upfeed data to the parent function.
marker hottie.4th
seq
w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
constant person
: init-person ( str node -- node )
init-seq >r
[char] M r@ .gender ! \ default is male
r> ;
: new-person ( str -- node )
person alloc
init-person ;
person
w field .hotness \ scale of 1 to 10
constant chick
: init-chick ( hotness str node -- node )
init-person >r
[char] F r@ .gender !
r@ .hotness !
r> ;
: new-chick ( hotness str -- node )
chick alloc
init-chick ;
: test { head | people chicks tens nines eights -- }
head r[
1 +to people
dup .gender @ [char] F = if 1 +to chicks
.hotness @
dup 8 = if 1 +to eights then
dup 9 = if 1 +to nines then
10 = if 1 +to tens then \ Yay! We found at least one!
else drop then
]r |each
cr ." total people: " people .
cr ." total chicks: " chicks .
cr ." level 10 chicks: " tens .
cr ." level 9 chicks: " nines .
cr ." level 8 chicks: " eights .
;
\ The following is an example list of people.
nil
c" aaaaa" new-person link
c" bbbbb" new-person link
3 c" ccccc" new-chick link
10 c" Darby" new-chick link
8 c" eeeee" new-chick link
c" fffff" new-person link
7 c" ggggg" new-chick link
8 c" hhhhh" new-chick link
constant people
Here is a test of the code:
people show-seq
aaaaa
bbbbb
ccccc
Darby
eeeee
fffff
ggggg
hhhhh
ok
people test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
So, Forth-200x enthusiasts, how would you write the hottie-counting code in Forth-200x with your Paysan-faked quotations? Would you rely on global variables?
I know how to write it without global variables, and make it reasonably clear code (although not as clear as what I have above). I will leave this as an exercise for the comp.lang.forth crowd for a few days before I post my code. Hint: you have to do this in the C way, and you have to put your struct on the heap because you can't have structs on the local-stack in ANS-Forth.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-07-29 00:50 +0000 |
| Message-ID | <nne982$a7h$1@dont-email.me> |
| In reply to | #49631 |
> \ This needs NOVICE.4TH and LIST.4TH loaded.
> \ This demonstrates how rquotations can upfeed data to the parent function.
>
> marker hottie.4th
>
>
> seq
> w field .gender \ 'M' or 'F'
Only words have the characteristic "gender".
Humans are of the male sex or the female sex.
> \ if someone isn't one or the other, then he/she isn't a person
> constant person
>
> : init-person ( str node -- node )
> init-seq >r
> [char] M r@ .gender ! \ default is male
> r> ;
>
> : new-person ( str -- node )
> person alloc
> init-person ;
>
> person
> w field .hotness \ scale of 1 to 10
> constant chick
>
> : init-chick ( hotness str node -- node )
> init-person >r
> [char] F r@ .gender !
> r@ .hotness !
> r> ;
>
> : new-chick ( hotness str -- node )
> chick alloc
> init-chick ;
>
> : test { head | people chicks tens nines eights -- }
> head r[
> 1 +to people
> dup .gender @ [char] F = if 1 +to chicks
> .hotness @
> dup 8 = if 1 +to eights then
> dup 9 = if 1 +to nines then
> 10 = if 1 +to tens then \ Yay! We found at least one!
> else drop then
> ]r |each
> cr ." total people: " people .
> cr ." total chicks: " chicks .
> cr ." level 10 chicks: " tens .
> cr ." level 9 chicks: " nines .
> cr ." level 8 chicks: " eights .
> ;
>
> \ The following is an example list of people.
>
> nil
> c" aaaaa" new-person link
> c" bbbbb" new-person link
> 3 c" ccccc" new-chick link
> 10 c" Darby" new-chick link
> 8 c" eeeee" new-chick link
> c" fffff" new-person link
> 7 c" ggggg" new-chick link
> 8 c" hhhhh" new-chick link
> constant people
>
>
> Here is a test of the code:
>
> people show-seq
> aaaaa
> bbbbb
> ccccc
> Darby
> eeeee
> fffff
> ggggg
> hhhhh
> ok
> people test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
OCaml:
type person = {name:string; sex:char; hotness:int} ;;
let new_man name = {name=name; sex='m'; hotness=0};;
let new_chick name hot = {name=name; sex='f'; hotness=hot} ;;
let people = [new_man "aaa"; new_man "bbb"; new_chick "ccc" 3;
new_chick "Darby" 10; new_chick "eee" 8; new_man "fff";
new_chick "ggg" 7; new_chick "hhh" 8];;
open Printf ;;
let report persons =
let heat = Array.make 11 0 and
chick_count = ref 0 and
person_count = ref 0 in
List.iter
(fun person ->
incr person_count ;
if 'f' = person.sex then
( incr chick_count ;
let i = person.hotness in heat.(i) <- heat.(i) + 1 ))
persons ;
printf "Total people: %3d\n" !person_count ;
printf "Total chicks: %3d\n" !chick_count ;
for i = 10 downto 1 do
printf "Level %2d chicks: %3d\n" i heat.(i)
done ;;
report people;;
Total people: 8
Total chicks: 5
Level 10 chicks: 1
Level 9 chicks: 0
Level 8 chicks: 2
Level 7 chicks: 1
Level 6 chicks: 0
Level 5 chicks: 0
Level 4 chicks: 0
Level 3 chicks: 1
Level 2 chicks: 0
Level 1 chicks: 0
--
Again, commenters focused on the double standard whereby Jews advocate
multiculturalism and immigration for Europe, but have Israel as an avowedly
Jewish state to fall back on....
theoccidentalobserver.net/2015/11/douglas-murrays-warning-to-the-jewish-community
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-11 12:15 -0700 |
| Message-ID | <7f6dfd3e-2ada-4d08-9347-bf2879f054fe@googlegroups.com> |
| In reply to | #49631 |
On Thursday, July 28, 2016 at 4:29:15 PM UTC-7, hughag...@gmail.com wrote:
> Anyway, since I now have |EACH available in LIST.4TH I went ahead and compiled my hottie-counting program. I modified it slightly so that it would inherit from SEQ rather than LIST which simplifies it slightly. Here is the program:
>
> \ This needs NOVICE.4TH and LIST.4TH loaded.
> \ This demonstrates how rquotations can upfeed data to the parent function.
>
> marker hottie.4th
>
>
> seq
> w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
> constant person
>
> : init-person ( str node -- node )
> init-seq >r
> [char] M r@ .gender ! \ default is male
> r> ;
>
> : new-person ( str -- node )
> person alloc
> init-person ;
>
> person
> w field .hotness \ scale of 1 to 10
> constant chick
>
> : init-chick ( hotness str node -- node )
> init-person >r
> [char] F r@ .gender !
> r@ .hotness !
> r> ;
>
> : new-chick ( hotness str -- node )
> chick alloc
> init-chick ;
>
> : test { head | people chicks tens nines eights -- }
> head r[
> 1 +to people
> dup .gender @ [char] F = if 1 +to chicks
> .hotness @
> dup 8 = if 1 +to eights then
> dup 9 = if 1 +to nines then
> 10 = if 1 +to tens then \ Yay! We found at least one!
> else drop then
> ]r |each
> cr ." total people: " people .
> cr ." total chicks: " chicks .
> cr ." level 10 chicks: " tens .
> cr ." level 9 chicks: " nines .
> cr ." level 8 chicks: " eights .
> ;
>
> \ The following is an example list of people.
>
> nil
> c" aaaaa" new-person link
> c" bbbbb" new-person link
> 3 c" ccccc" new-chick link
> 10 c" Darby" new-chick link
> 8 c" eeeee" new-chick link
> c" fffff" new-person link
> 7 c" ggggg" new-chick link
> 8 c" hhhhh" new-chick link
> constant people
>
>
> Here is a test of the code:
>
> people show-seq
> aaaaa
> bbbbb
> ccccc
> Darby
> eeeee
> fffff
> ggggg
> hhhhh
> ok
> people test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
>
>
> So, Forth-200x enthusiasts, how would you write the hottie-counting code in Forth-200x with your Paysan-faked quotations? Would you rely on global variables?
>
> I know how to write it without global variables, and make it reasonably clear code (although not as clear as what I have above). I will leave this as an exercise for the comp.lang.forth crowd for a few days before I post my code. Hint: you have to do this in the C way, and you have to put your struct on the heap because you can't have structs on the local-stack in ANS-Forth.
Well, none of the Forth-200x enthusiasts wrote a hottie-counting program without using global variables or rquotations --- not a big surprise there --- the Forth-200x enthusiasts are mostly enthusiastic about claiming to be qualified to lead common Forth programmers such as myself, but are much less enthusiastic about writing Forth code that works.
Here, once again, is my TEST using rquotations:
: test { head | people chicks tens nines eights -- }
head r[
1 +to people
dup .gender @ [char] F = if 1 +to chicks
.hotness @
dup 8 = if 1 +to eights then
dup 9 = if 1 +to nines then
10 = if 1 +to tens then \ Yay! We found at least one!
else drop then
]r |each
cr ." total people: " people .
cr ." total chicks: " chicks .
cr ." level 10 chicks: " tens .
cr ." level 9 chicks: " nines .
cr ." level 8 chicks: " eights .
;
In some cases, the HOF is available as a pair of macros --- such as EACH[ and ]EACH in LIST.4TH --- C programmers do this using #DEFINE when they can, but this isn't always possible. In this case we have MACRO-TEST in ANS-Forth that is pretty comparable to the rquotation version in regards to brevity and readability:
: macro-test { head | people chicks tens nines eights -- }
head each[
1 +to people
dup .gender @ [char] F = if 1 +to chicks
.hotness @
dup 8 = if 1 +to eights then
dup 9 = if 1 +to nines then
10 = if 1 +to tens then \ Yay! We found at least one!
else drop then
]each
cr ." total people: " people .
cr ." total chicks: " chicks .
cr ." level 10 chicks: " tens .
cr ." level 9 chicks: " nines .
cr ." level 8 chicks: " eights .
;
If it is not possible to write the HOF as a pair of macros, such as in a more complicated data-structure than a singly-linked list, then the HOF has to be a function --- such as EACH in LIST.4TH --- C programmers do this too. In this case we have MACRO-TEST in ANS-Forth that is big and ugly:
0
w field .people
w field .chicks
w field .tens
w field .nines
w field .eights
constant heap-test-locals
: <heap-test> ( ^locals node -- )
over >r
1 r@ .people +!
dup .gender @ [char] F = if 1 r@ .chicks +!
.hotness @
dup 8 = if 1 r@ .eights +! then
dup 9 = if 1 r@ .nines +! then
10 = if 1 r@ .tens +! then
else drop then
rdrop ;
: heap-test ( head -- )
heap-test-locals alloc
0 over .people !
0 over .chicks !
0 over .tens !
0 over .nines !
0 over .eights !
swap ['] <heap-test> each
cr ." total people: " dup .people @ .
cr ." total chicks: " dup .chicks @ .
cr ." level 10 chicks: " dup .tens @ .
cr ." level 9 chicks: " dup .nines @ .
cr ." level 8 chicks: " dup .eights @ .
dealloc ;
This is definitely ugly Forth code, but it would be even uglier in C. In C the type-checking gets in the way. The pointer to the struct on the heap has to be passed in to the HOF as a void pointer because the HOF is general-purpose and doesn't know about this particular struct. In the pseudo-quotation the void pointer would then be type-cast back into a HEAP-TEST-LOCALS type pointer so the pseudo-quotation can access the fields.
All in all, this is horribly ugly! This is why C programmers rely as much as possible on #DEFINE macros for their HOFs. Macros don't always work though. In more complicated data-structures this may not work, in which case only the super-ugly technique is possible. This is true of both C and ANS-Forth --- the ANS-Forth macros are just text substitution too.
The rquotations seem to be the most robust solution. This is clean and simple, and it always works!
BTW: here is a test run under VFX:
try hottie.4th
Including hottie.4th ok
people show-seq
aaaaa
bbbbb
ccccc
Darby
eeeee
fffff
ggggg
hhhhh
ok
people test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
people macro-test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
people heap-test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-11 13:25 -0700 |
| Message-ID | <dff4336b-cf35-40c5-9a4c-0bc753a047f3@googlegroups.com> |
| In reply to | #49956 |
On Thursday, August 11, 2016 at 2:15:04 PM UTC-5, hughag...@gmail.com wrote: > > Well, none of the Forth-200x enthusiasts wrote a hottie-counting program without using global variables or rquotations --- not a big surprise there --- the Forth-200x enthusiasts are mostly enthusiastic about claiming to be qualified to lead common Forth programmers such as myself, but are much less enthusiastic about writing Forth code that works. > Well it's been a while, so: web search, "why are global variables bad?" First result: http://c2.com/cgi/wiki?GlobalVariablesAreBad > Why Global Variables Should be Avoided When Unnecessary > * Non-locality This doesn't apply well to Forth, and doesn't at all to my example alternative to your code, which could trivially behead the internal words a little bit leader, or hide them in a private wordlist. With PACKAGE PUBLIC PRIVATE END-PACKAGE , doing so is not even awkward. This doesn't apply well to Forth because definitions in Forth are only extant from their definition and for *subsequent* code when they are in the search order. Absent an explicit DEFER ,you do not see a word used in Forth before you've seen its definition. You can always scroll up, or look in previously included code, to see a word's definition. It may seem like I'm saying nothing, or nothing important. But this completely changes what it means for a 'variable' to be 'global'. Forth does not have global variables. It has an ordered dictionary of words, and some of those words push an address to the stack. > * No Access Control or Constraint Checking There isn't with locals either. If you want this in Forth, you write access words and use those. People using other languages are probably less concerned about 'access control' against locals because they can easily read such code (many of these complaints are restatements of the Non-locality complaint). Forth's ordered dictionary makes it easy to read code involving 'globals' as well. > * Implicit coupling > * Concurrency issues Yes, concurrency comes with issues. > Namespace pollution - Global names are available everywhere. You > may unknowingly end up using a global when you think you are using > a local (by misspelling or forgetting to declare the local) or > vice versa. Also, if you ever have to link together modules that > have the same global variable names, if you are lucky, you will > get linking errors. If you are unlucky, the linker will simply > treat all uses of the same name as the same object. Quoting this in full to underline how inappropriate it is to Forth. > Memory allocation issues Yes, ALLOCATE comes with issues. > Testing and Confinement - source that utilizes globals is somewhat > more difficult to test because one cannot readily set up a 'clean' > environment between runs. More generally, source that utilizes > global services of any sort (e.g. reading and writing files or > databases) that aren't explicitly provided to that source is > difficult to test for the same reason. For communicating systems, > the ability to test system invariants may require running more > than one 'copy' of a system simultaneously, which is greatly > hindered by any use of shared services - including global memory - > that are not provided for sharing as part of the test. Likewise, quoting in full. This is the last complaint. Forth's dictionary helps a lot, but 'global variables' are a small part of this complaint about global variables. Meanwhile: > Some people jump through very complicated hoops to avoid using > globals. Many uses of the SingletonPattern are just thinly veiled > globals. If something really should be a global, make it a global. > Don't do something complicated because you might need it someday. In Forth, *using local variables* is jumping through hoops to avoid the stack or the 'global variables' that Forth doesn't have. Certainly, using five local variables and counting into them is a weird thing to do in what looks like some kind of statistics app. Later, Alternatives to Global Variables: > Hidden Globals -- hidden globals have a well-defined access scope, > and would include, for example, private 'static' variables in > classes and 'static' variables in '.c' files and variables in > anonymous namespaces in C++. This solution cages and localizes > globals rather than tames them - you'll still get bitten when it > comes to concurrency and modularization and testing/confinement, > but at least all such problems will be localized and easy to > repair, and there won't be linking problems. Look at that. They're almost talking about Forth. Forth's non-global global variables (with well-defined access scopes that are easily limited to associated code) are actually an alternative to these 'global variables' that you keep speaking against. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-11 20:57 -0700 |
| Message-ID | <ea81c312-443b-4a07-9ad1-d2a43378b767@googlegroups.com> |
| In reply to | #49959 |
On Thursday, August 11, 2016 at 1:25:46 PM UTC-7, Julian Fondren wrote: > It may seem like I'm saying nothing, or nothing important. Yep!
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-11 13:59 -0700 |
| Message-ID | <a02023a2-543f-44e4-8815-c841e56db89c@googlegroups.com> |
| In reply to | #49956 |
On Thursday, August 11, 2016 at 10:15:04 PM UTC+3, hughag...@gmail.com wrote:
> On Thursday, July 28, 2016 at 4:29:15 PM UTC-7, hughag...@gmail.com wrote:
> > Anyway, since I now have |EACH available in LIST.4TH I went ahead and compiled my hottie-counting program. I modified it slightly so that it would inherit from SEQ rather than LIST which simplifies it slightly. Here is the program:
> >
> > \ This needs NOVICE.4TH and LIST.4TH loaded.
> > \ This demonstrates how rquotations can upfeed data to the parent function.
> >
> > marker hottie.4th
> >
> >
> > seq
> > w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
> > constant person
> >
> > : init-person ( str node -- node )
> > init-seq >r
> > [char] M r@ .gender ! \ default is male
> > r> ;
> >
> > : new-person ( str -- node )
> > person alloc
> > init-person ;
> >
> > person
> > w field .hotness \ scale of 1 to 10
> > constant chick
> >
> > : init-chick ( hotness str node -- node )
> > init-person >r
> > [char] F r@ .gender !
> > r@ .hotness !
> > r> ;
> >
> > : new-chick ( hotness str -- node )
> > chick alloc
> > init-chick ;
> >
> > : test { head | people chicks tens nines eights -- }
> > head r[
> > 1 +to people
> > dup .gender @ [char] F = if 1 +to chicks
> > .hotness @
> > dup 8 = if 1 +to eights then
> > dup 9 = if 1 +to nines then
> > 10 = if 1 +to tens then \ Yay! We found at least one!
> > else drop then
> > ]r |each
> > cr ." total people: " people .
> > cr ." total chicks: " chicks .
> > cr ." level 10 chicks: " tens .
> > cr ." level 9 chicks: " nines .
> > cr ." level 8 chicks: " eights .
> > ;
> >
> > \ The following is an example list of people.
> >
> > nil
> > c" aaaaa" new-person link
> > c" bbbbb" new-person link
> > 3 c" ccccc" new-chick link
> > 10 c" Darby" new-chick link
> > 8 c" eeeee" new-chick link
> > c" fffff" new-person link
> > 7 c" ggggg" new-chick link
> > 8 c" hhhhh" new-chick link
> > constant people
> >
> >
> > Here is a test of the code:
> >
> > people show-seq
> > aaaaa
> > bbbbb
> > ccccc
> > Darby
> > eeeee
> > fffff
> > ggggg
> > hhhhh
> > ok
> > people test
> > total people: 8
> > total chicks: 5
> > level 10 chicks: 1
> > level 9 chicks: 0
> > level 8 chicks: 2 ok
> >
> >
> > So, Forth-200x enthusiasts, how would you write the hottie-counting code in Forth-200x with your Paysan-faked quotations? Would you rely on global variables?
> >
> > I know how to write it without global variables, and make it reasonably clear code (although not as clear as what I have above). I will leave this as an exercise for the comp.lang.forth crowd for a few days before I post my code. Hint: you have to do this in the C way, and you have to put your struct on the heap because you can't have structs on the local-stack in ANS-Forth.
>
> Well, none of the Forth-200x enthusiasts wrote a hottie-counting program without using global variables or rquotations --- not a big surprise there --- the Forth-200x enthusiasts are mostly enthusiastic about claiming to be qualified to lead common Forth programmers such as myself, but are much less enthusiastic about writing Forth code that works.
>
> Here, once again, is my TEST using rquotations:
>
> : test { head | people chicks tens nines eights -- }
> head r[
> 1 +to people
> dup .gender @ [char] F = if 1 +to chicks
> .hotness @
> dup 8 = if 1 +to eights then
> dup 9 = if 1 +to nines then
> 10 = if 1 +to tens then \ Yay! We found at least one!
> else drop then
> ]r |each
> cr ." total people: " people .
> cr ." total chicks: " chicks .
> cr ." level 10 chicks: " tens .
> cr ." level 9 chicks: " nines .
> cr ." level 8 chicks: " eights .
> ;
>
> In some cases, the HOF is available as a pair of macros --- such as EACH[ and ]EACH in LIST.4TH --- C programmers do this using #DEFINE when they can, but this isn't always possible. In this case we have MACRO-TEST in ANS-Forth that is pretty comparable to the rquotation version in regards to brevity and readability:
>
> : macro-test { head | people chicks tens nines eights -- }
> head each[
> 1 +to people
> dup .gender @ [char] F = if 1 +to chicks
> .hotness @
> dup 8 = if 1 +to eights then
> dup 9 = if 1 +to nines then
> 10 = if 1 +to tens then \ Yay! We found at least one!
> else drop then
> ]each
> cr ." total people: " people .
> cr ." total chicks: " chicks .
> cr ." level 10 chicks: " tens .
> cr ." level 9 chicks: " nines .
> cr ." level 8 chicks: " eights .
> ;
>
> If it is not possible to write the HOF as a pair of macros, such as in a more complicated data-structure than a singly-linked list, then the HOF has to be a function --- such as EACH in LIST.4TH --- C programmers do this too. In this case we have MACRO-TEST in ANS-Forth that is big and ugly:
>
> 0
> w field .people
> w field .chicks
> w field .tens
> w field .nines
> w field .eights
> constant heap-test-locals
>
> : <heap-test> ( ^locals node -- )
> over >r
> 1 r@ .people +!
> dup .gender @ [char] F = if 1 r@ .chicks +!
> .hotness @
> dup 8 = if 1 r@ .eights +! then
> dup 9 = if 1 r@ .nines +! then
> 10 = if 1 r@ .tens +! then
> else drop then
> rdrop ;
>
> : heap-test ( head -- )
> heap-test-locals alloc
> 0 over .people !
> 0 over .chicks !
> 0 over .tens !
> 0 over .nines !
> 0 over .eights !
> swap ['] <heap-test> each
> cr ." total people: " dup .people @ .
> cr ." total chicks: " dup .chicks @ .
> cr ." level 10 chicks: " dup .tens @ .
> cr ." level 9 chicks: " dup .nines @ .
> cr ." level 8 chicks: " dup .eights @ .
> dealloc ;
>
> This is definitely ugly Forth code, but it would be even uglier in C. In C the type-checking gets in the way. The pointer to the struct on the heap has to be passed in to the HOF as a void pointer because the HOF is general-purpose and doesn't know about this particular struct. In the pseudo-quotation the void pointer would then be type-cast back into a HEAP-TEST-LOCALS type pointer so the pseudo-quotation can access the fields.
>
> All in all, this is horribly ugly! This is why C programmers rely as much as possible on #DEFINE macros for their HOFs. Macros don't always work though. In more complicated data-structures this may not work, in which case only the super-ugly technique is possible. This is true of both C and ANS-Forth --- the ANS-Forth macros are just text substitution too.
>
> The rquotations seem to be the most robust solution. This is clean and simple, and it always works!
>
> BTW: here is a test run under VFX:
>
> try hottie.4th
> Including hottie.4th ok
> people show-seq
> aaaaa
> bbbbb
> ccccc
> Darby
> eeeee
> fffff
> ggggg
> hhhhh
> ok
> people test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
> people macro-test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
> people heap-test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
Hi!
just a prettified classic version:
: ++ ( a -- )
1 swap +!
;
0
w field .people
w field .chicks
w field .tens
w field .nines
w field .eights
constant test-locals
: .locals ( ^local -- )
dup .people ?
dup .people ?
dup .chicks ?
dup .tens ?
dup .nines ?
.eights ?
;
: <test> ( ^locals node -- ^locals )
over .people ++
dup .gender @ [char] F = IF
over .chicks ++
.hotness @
dup 8 = IF over .eights ++ THEN
dup 9 = IF over .nines ++ THEN
10 = IF dup .tens ++ THEN
ELSE
drop
THEN
;
: test ( head -- )
align here dup test-locals dup allot 0 fill
swap ['] <test> each
.locals
test-locals negate allot
;
--
Have a nice day,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-11 21:11 -0700 |
| Message-ID | <d136456a-b71e-46b5-b3a9-62636c7c1e7f@googlegroups.com> |
| In reply to | #49960 |
On Thursday, August 11, 2016 at 1:59:41 PM UTC-7, humptydumpty wrote:
> On Thursday, August 11, 2016 at 10:15:04 PM UTC+3, hughag...@gmail.com wrote:
> > On Thursday, July 28, 2016 at 4:29:15 PM UTC-7, hughag...@gmail.com wrote:
> > > Anyway, since I now have |EACH available in LIST.4TH I went ahead and compiled my hottie-counting program. I modified it slightly so that it would inherit from SEQ rather than LIST which simplifies it slightly. Here is the program:
> > >
> > > \ This needs NOVICE.4TH and LIST.4TH loaded.
> > > \ This demonstrates how rquotations can upfeed data to the parent function.
> > >
> > > marker hottie.4th
> > >
> > >
> > > seq
> > > w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
> > > constant person
> > >
> > > : init-person ( str node -- node )
> > > init-seq >r
> > > [char] M r@ .gender ! \ default is male
> > > r> ;
> > >
> > > : new-person ( str -- node )
> > > person alloc
> > > init-person ;
> > >
> > > person
> > > w field .hotness \ scale of 1 to 10
> > > constant chick
> > >
> > > : init-chick ( hotness str node -- node )
> > > init-person >r
> > > [char] F r@ .gender !
> > > r@ .hotness !
> > > r> ;
> > >
> > > : new-chick ( hotness str -- node )
> > > chick alloc
> > > init-chick ;
> > >
> > > : test { head | people chicks tens nines eights -- }
> > > head r[
> > > 1 +to people
> > > dup .gender @ [char] F = if 1 +to chicks
> > > .hotness @
> > > dup 8 = if 1 +to eights then
> > > dup 9 = if 1 +to nines then
> > > 10 = if 1 +to tens then \ Yay! We found at least one!
> > > else drop then
> > > ]r |each
> > > cr ." total people: " people .
> > > cr ." total chicks: " chicks .
> > > cr ." level 10 chicks: " tens .
> > > cr ." level 9 chicks: " nines .
> > > cr ." level 8 chicks: " eights .
> > > ;
> > >
> > > \ The following is an example list of people.
> > >
> > > nil
> > > c" aaaaa" new-person link
> > > c" bbbbb" new-person link
> > > 3 c" ccccc" new-chick link
> > > 10 c" Darby" new-chick link
> > > 8 c" eeeee" new-chick link
> > > c" fffff" new-person link
> > > 7 c" ggggg" new-chick link
> > > 8 c" hhhhh" new-chick link
> > > constant people
> > >
> > >
> > > Here is a test of the code:
> > >
> > > people show-seq
> > > aaaaa
> > > bbbbb
> > > ccccc
> > > Darby
> > > eeeee
> > > fffff
> > > ggggg
> > > hhhhh
> > > ok
> > > people test
> > > total people: 8
> > > total chicks: 5
> > > level 10 chicks: 1
> > > level 9 chicks: 0
> > > level 8 chicks: 2 ok
> > >
> > >
> > > So, Forth-200x enthusiasts, how would you write the hottie-counting code in Forth-200x with your Paysan-faked quotations? Would you rely on global variables?
> > >
> > > I know how to write it without global variables, and make it reasonably clear code (although not as clear as what I have above). I will leave this as an exercise for the comp.lang.forth crowd for a few days before I post my code. Hint: you have to do this in the C way, and you have to put your struct on the heap because you can't have structs on the local-stack in ANS-Forth.
> >
> > Well, none of the Forth-200x enthusiasts wrote a hottie-counting program without using global variables or rquotations --- not a big surprise there --- the Forth-200x enthusiasts are mostly enthusiastic about claiming to be qualified to lead common Forth programmers such as myself, but are much less enthusiastic about writing Forth code that works.
> >
> > Here, once again, is my TEST using rquotations:
> >
> > : test { head | people chicks tens nines eights -- }
> > head r[
> > 1 +to people
> > dup .gender @ [char] F = if 1 +to chicks
> > .hotness @
> > dup 8 = if 1 +to eights then
> > dup 9 = if 1 +to nines then
> > 10 = if 1 +to tens then \ Yay! We found at least one!
> > else drop then
> > ]r |each
> > cr ." total people: " people .
> > cr ." total chicks: " chicks .
> > cr ." level 10 chicks: " tens .
> > cr ." level 9 chicks: " nines .
> > cr ." level 8 chicks: " eights .
> > ;
> >
> > In some cases, the HOF is available as a pair of macros --- such as EACH[ and ]EACH in LIST.4TH --- C programmers do this using #DEFINE when they can, but this isn't always possible. In this case we have MACRO-TEST in ANS-Forth that is pretty comparable to the rquotation version in regards to brevity and readability:
> >
> > : macro-test { head | people chicks tens nines eights -- }
> > head each[
> > 1 +to people
> > dup .gender @ [char] F = if 1 +to chicks
> > .hotness @
> > dup 8 = if 1 +to eights then
> > dup 9 = if 1 +to nines then
> > 10 = if 1 +to tens then \ Yay! We found at least one!
> > else drop then
> > ]each
> > cr ." total people: " people .
> > cr ." total chicks: " chicks .
> > cr ." level 10 chicks: " tens .
> > cr ." level 9 chicks: " nines .
> > cr ." level 8 chicks: " eights .
> > ;
> >
> > If it is not possible to write the HOF as a pair of macros, such as in a more complicated data-structure than a singly-linked list, then the HOF has to be a function --- such as EACH in LIST.4TH --- C programmers do this too. In this case we have MACRO-TEST in ANS-Forth that is big and ugly:
> >
> > 0
> > w field .people
> > w field .chicks
> > w field .tens
> > w field .nines
> > w field .eights
> > constant heap-test-locals
> >
> > : <heap-test> ( ^locals node -- )
> > over >r
> > 1 r@ .people +!
> > dup .gender @ [char] F = if 1 r@ .chicks +!
> > .hotness @
> > dup 8 = if 1 r@ .eights +! then
> > dup 9 = if 1 r@ .nines +! then
> > 10 = if 1 r@ .tens +! then
> > else drop then
> > rdrop ;
> >
> > : heap-test ( head -- )
> > heap-test-locals alloc
> > 0 over .people !
> > 0 over .chicks !
> > 0 over .tens !
> > 0 over .nines !
> > 0 over .eights !
> > swap ['] <heap-test> each
> > cr ." total people: " dup .people @ .
> > cr ." total chicks: " dup .chicks @ .
> > cr ." level 10 chicks: " dup .tens @ .
> > cr ." level 9 chicks: " dup .nines @ .
> > cr ." level 8 chicks: " dup .eights @ .
> > dealloc ;
> >
> > This is definitely ugly Forth code, but it would be even uglier in C. In C the type-checking gets in the way. The pointer to the struct on the heap has to be passed in to the HOF as a void pointer because the HOF is general-purpose and doesn't know about this particular struct. In the pseudo-quotation the void pointer would then be type-cast back into a HEAP-TEST-LOCALS type pointer so the pseudo-quotation can access the fields.
> >
> > All in all, this is horribly ugly! This is why C programmers rely as much as possible on #DEFINE macros for their HOFs. Macros don't always work though. In more complicated data-structures this may not work, in which case only the super-ugly technique is possible. This is true of both C and ANS-Forth --- the ANS-Forth macros are just text substitution too.
> >
> > The rquotations seem to be the most robust solution. This is clean and simple, and it always works!
> >
> > BTW: here is a test run under VFX:
> >
> > try hottie.4th
> > Including hottie.4th ok
> > people show-seq
> > aaaaa
> > bbbbb
> > ccccc
> > Darby
> > eeeee
> > fffff
> > ggggg
> > hhhhh
> > ok
> > people test
> > total people: 8
> > total chicks: 5
> > level 10 chicks: 1
> > level 9 chicks: 0
> > level 8 chicks: 2 ok
> > people macro-test
> > total people: 8
> > total chicks: 5
> > level 10 chicks: 1
> > level 9 chicks: 0
> > level 8 chicks: 2 ok
> > people heap-test
> > total people: 8
> > total chicks: 5
> > level 10 chicks: 1
> > level 9 chicks: 0
> > level 8 chicks: 2 ok
>
> Hi!
> just a prettified classic version:
>
> : ++ ( a -- )
> 1 swap +!
> ;
> 0
> w field .people
> w field .chicks
> w field .tens
> w field .nines
> w field .eights
> constant test-locals
>
> : .locals ( ^local -- )
> dup .people ?
> dup .people ?
> dup .chicks ?
> dup .tens ?
> dup .nines ?
> .eights ?
> ;
> : <test> ( ^locals node -- ^locals )
> over .people ++
> dup .gender @ [char] F = IF
> over .chicks ++
> .hotness @
> dup 8 = IF over .eights ++ THEN
> dup 9 = IF over .nines ++ THEN
> 10 = IF dup .tens ++ THEN
> ELSE
> drop
> THEN
> ;
> : test ( head -- )
> align here dup test-locals dup allot 0 fill
> swap ['] <test> each
> .locals
> test-locals negate allot
> ;
I agree that ++ does improve the readability. I actually have that in the novice-package, but I just forgot about it.
What is the point of putting your TEST-LOCALS struct in the dictionary rather than the heap? Is that faster?
I still think that this is quite ugly, even if it is prettified slightly. We have this struct definition out in global memory polluting the namespace, but it is only used inside of <TEST> and TEST --- it should be local --- making local variables local is the whole point of the rquotations.
> Have a nice day,
> humptydumpty
You too! :-)
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-08-12 00:30 -0700 |
| Message-ID | <88d807db-87e1-446a-a82f-e9d182afb8c8@googlegroups.com> |
| In reply to | #49971 |
On Thursday, August 11, 2016 at 11:11:24 PM UTC-5, hughag...@gmail.com wrote: > I agree that ++ does improve the readability. Unfortunately its companion -- suffers from being quite hard to search for in a body of Forth code. It also disappears in English text. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-08-13 11:33 -0700 |
| Message-ID | <ff0efbda-4547-4f1c-a327-1df1370e211a@googlegroups.com> |
| In reply to | #49987 |
On Friday, August 12, 2016 at 3:30:19 AM UTC-4, Julian Fondren wrote: > On Thursday, August 11, 2016 at 11:11:24 PM UTC-5, hughag...@gmail.com wrote: > > I agree that ++ does improve the readability. > > Unfortunately its companion -- suffers from being quite > hard to search for in a body of Forth code. It also > disappears in English text. > > > -- Julian HsForth provided 1+! and of course 1-!. These seem like more Forth like names, however I must confess that I like '++'. BF
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <htrofhc@gmail.com> |
|---|---|
| Date | 2016-08-13 21:22 +0200 |
| Message-ID | <l72le0clqwwe.1xa5sbsasbkf$.dlg@40tude.net> |
| In reply to | #50053 |
Op Sat, 13 Aug 2016 11:33:08 -0700 (PDT) schreef foxaudioresearch@gmail.com: > On Friday, August 12, 2016 at 3:30:19 AM UTC-4, Julian Fondren wrote: >> On Thursday, August 11, 2016 at 11:11:24 PM UTC-5, hughag...@gmail.com wrote: >>> I agree that ++ does improve the readability. >> >> Unfortunately its companion -- suffers from being quite >> hard to search for in a body of Forth code. It also >> disappears in English text. >> >> >> -- Julian > > HsForth provided 1+! and of course 1-!. > These seem like more Forth like names, however I must confess that I like '++'. > > BF I've used INCR and DECR But I've seen them as prefixes for values like TO I still use ON and OFF groet Coos
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-12 11:05 -0700 |
| Message-ID | <036a51c0-c293-46ad-9137-9529fdb4bb5f@googlegroups.com> |
| In reply to | #49971 |
On Thursday, August 11, 2016 at 9:11:24 PM UTC-7, hughag...@gmail.com wrote:
> I agree that ++ does improve the readability. I actually have that in the novice-package, but I just forgot about it.
>
> What is the point of putting your TEST-LOCALS struct in the dictionary rather than the heap? Is that faster?
As I said, I already have ++ in the novice package. I didn't have ? though. I already have ZALLOT but I didn't have ZALLOC --- I have all of these now; here they are:
macro: ++ ( adr -- )
1 swap +! ;
macro: ? ( adr -- )
@ . ;
: zalloc ( size -- adr )
dup alloc \ -- size adr
tuck swap erase ;
BTW: Can you think of a good name for the TUCK SWAP stack-juggler? That seems like it should be factored out, but I can't think of a name for it.
I am still uncomfortable with using the dictionary rather than the heap. In a simple program like this it will work --- it could get messed up though if sub-functions are also using the dictionary and leaving data there --- this is similar to PAD in that it has reentrancy problems that could bite you.
I still think the rquotations version is the best, and it doesn't need any prettification. Here are some slightly prettified upgrades to all of the different versions:
marker hottie.4th
seq
w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
constant person
: init-person ( str node -- node )
init-seq >r
[char] M r@ .gender ! \ default is male
r> ;
: new-person ( str -- node )
person alloc
init-person ;
person
w field .hotness \ scale of 1 to 10
constant chick
: init-chick ( hotness str node -- node )
init-person >r
[char] F r@ .gender !
r@ .hotness !
r> ;
: new-chick ( hotness str -- node )
chick alloc
init-chick ;
: test { head | people chicks tens nines eights -- }
head r[
1 +to people
dup .gender @ [char] F = if 1 +to chicks
.hotness @
dup 8 = if 1 +to eights then
dup 9 = if 1 +to nines then
10 = if 1 +to tens then \ Yay! We found at least one!
else drop then
]r |each
cr ." total people: " people .
cr ." total chicks: " chicks .
cr ." level 10 chicks: " tens .
cr ." level 9 chicks: " nines .
cr ." level 8 chicks: " eights .
;
\ If the HOF can be written as a pair of macros --- such as EACH[ ]EACH --- then MACRO-TEST can be used:
: macro-test { head | people chicks tens nines eights -- }
head each[
1 +to people
dup .gender @ [char] F = if 1 +to chicks
.hotness @
dup 8 = if 1 +to eights then
dup 9 = if 1 +to nines then
10 = if 1 +to tens then \ Yay! We found at least one!
else drop then
]each
cr ." total people: " people .
cr ." total chicks: " chicks .
cr ." level 10 chicks: " tens .
cr ." level 9 chicks: " nines .
cr ." level 8 chicks: " eights .
;
\ If the HOF has to be a function --- such as EACH --- then HEAP-TEST can be used:
0
w field .people
w field .chicks
w field .tens
w field .nines
w field .eights
constant test-locals
: <heap-test> ( ^locals node -- )
over >r
r@ .people ++
dup .gender @ [char] F = if r@ .chicks ++
.hotness @
dup 8 = if r@ .eights ++ then
dup 9 = if r@ .nines ++ then
10 = if r@ .tens ++ then
else drop then
rdrop ;
: heap-test ( head -- )
test-locals zalloc
swap ['] <heap-test> each
cr ." total people: " dup .people ?
cr ." total chicks: " dup .chicks ?
cr ." level 10 chicks: " dup .tens ?
cr ." level 9 chicks: " dup .nines ?
cr ." level 8 chicks: " dup .eights ?
dealloc ;
\ The following is HumptyDumpty's prettified version.
: .locals ( ^local -- )
dup .people ?
dup .chicks ?
dup .tens ?
dup .nines ?
.eights ?
;
: <HDtest> ( ^locals node -- ^locals )
over .people ++
dup .gender @ [char] F = IF
over .chicks ++
.hotness @
dup 8 = IF over .eights ++ THEN
dup 9 = IF over .nines ++ THEN
10 = IF dup .tens ++ THEN
ELSE
drop
THEN
;
: HDtest ( head -- )
align here test-locals zallot
swap ['] <HDtest> each
.locals
test-locals negate allot
;
\ The following is an example list of people.
nil
c" aaaaa" new-person link
c" bbbbb" new-person link
3 c" ccccc" new-chick link
10 c" Darby" new-chick link
8 c" eeeee" new-chick link
c" fffff" new-person link
7 c" ggggg" new-chick link
8 c" hhhhh" new-chick link
constant people
This is a test of the code:
try hottie.4th
Including hottie.4th ok
people show-seq
aaaaa
bbbbb
ccccc
Darby
eeeee
fffff
ggggg
hhhhh
ok
people test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
people macro-test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
people heap-test
total people: 8
total chicks: 5
level 10 chicks: 1
level 9 chicks: 0
level 8 chicks: 2 ok
people HDtest 8 5 1 0 2 ok
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-08-13 07:27 -0700 |
| Message-ID | <edd99383-1b05-4d31-a674-e3a5016b4eb5@googlegroups.com> |
| In reply to | #49999 |
On Friday, August 12, 2016 at 9:05:33 PM UTC+3, hughag...@gmail.com wrote:
> On Thursday, August 11, 2016 at 9:11:24 PM UTC-7, hughag...@gmail.com wrote:
> > I agree that ++ does improve the readability. I actually have that in the novice-package, but I just forgot about it.
> >
> > What is the point of putting your TEST-LOCALS struct in the dictionary rather than the heap? Is that faster?
>
> As I said, I already have ++ in the novice package. I didn't have ? though. I already have ZALLOT but I didn't have ZALLOC --- I have all of these now; here they are:
>
> macro: ++ ( adr -- )
> 1 swap +! ;
>
> macro: ? ( adr -- )
> @ . ;
>
> : zalloc ( size -- adr )
> dup alloc \ -- size adr
> tuck swap erase ;
>
> BTW: Can you think of a good name for the TUCK SWAP stack-juggler? That seems like it should be factored out, but I can't think of a name for it.
>
> I am still uncomfortable with using the dictionary rather than the heap. In a simple program like this it will work --- it could get messed up though if sub-functions are also using the dictionary and leaving data there --- this is similar to PAD in that it has reentrancy problems that could bite you.
>
> I still think the rquotations version is the best, and it doesn't need any prettification. Here are some slightly prettified upgrades to all of the different versions:
>
> marker hottie.4th
>
>
> seq
> w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
> constant person
>
> : init-person ( str node -- node )
> init-seq >r
> [char] M r@ .gender ! \ default is male
> r> ;
>
> : new-person ( str -- node )
> person alloc
> init-person ;
>
> person
> w field .hotness \ scale of 1 to 10
> constant chick
>
> : init-chick ( hotness str node -- node )
> init-person >r
> [char] F r@ .gender !
> r@ .hotness !
> r> ;
>
> : new-chick ( hotness str -- node )
> chick alloc
> init-chick ;
>
> : test { head | people chicks tens nines eights -- }
> head r[
> 1 +to people
> dup .gender @ [char] F = if 1 +to chicks
> .hotness @
> dup 8 = if 1 +to eights then
> dup 9 = if 1 +to nines then
> 10 = if 1 +to tens then \ Yay! We found at least one!
> else drop then
> ]r |each
> cr ." total people: " people .
> cr ." total chicks: " chicks .
> cr ." level 10 chicks: " tens .
> cr ." level 9 chicks: " nines .
> cr ." level 8 chicks: " eights .
> ;
>
> \ If the HOF can be written as a pair of macros --- such as EACH[ ]EACH --- then MACRO-TEST can be used:
>
> : macro-test { head | people chicks tens nines eights -- }
> head each[
> 1 +to people
> dup .gender @ [char] F = if 1 +to chicks
> .hotness @
> dup 8 = if 1 +to eights then
> dup 9 = if 1 +to nines then
> 10 = if 1 +to tens then \ Yay! We found at least one!
> else drop then
> ]each
> cr ." total people: " people .
> cr ." total chicks: " chicks .
> cr ." level 10 chicks: " tens .
> cr ." level 9 chicks: " nines .
> cr ." level 8 chicks: " eights .
> ;
>
> \ If the HOF has to be a function --- such as EACH --- then HEAP-TEST can be used:
>
> 0
> w field .people
> w field .chicks
> w field .tens
> w field .nines
> w field .eights
> constant test-locals
>
> : <heap-test> ( ^locals node -- )
> over >r
> r@ .people ++
> dup .gender @ [char] F = if r@ .chicks ++
> .hotness @
> dup 8 = if r@ .eights ++ then
> dup 9 = if r@ .nines ++ then
> 10 = if r@ .tens ++ then
> else drop then
> rdrop ;
>
> : heap-test ( head -- )
> test-locals zalloc
> swap ['] <heap-test> each
> cr ." total people: " dup .people ?
> cr ." total chicks: " dup .chicks ?
> cr ." level 10 chicks: " dup .tens ?
> cr ." level 9 chicks: " dup .nines ?
> cr ." level 8 chicks: " dup .eights ?
> dealloc ;
>
> \ The following is HumptyDumpty's prettified version.
>
> : .locals ( ^local -- )
> dup .people ?
> dup .chicks ?
> dup .tens ?
> dup .nines ?
> .eights ?
> ;
> : <HDtest> ( ^locals node -- ^locals )
> over .people ++
> dup .gender @ [char] F = IF
> over .chicks ++
> .hotness @
> dup 8 = IF over .eights ++ THEN
> dup 9 = IF over .nines ++ THEN
> 10 = IF dup .tens ++ THEN
> ELSE
> drop
> THEN
> ;
> : HDtest ( head -- )
> align here test-locals zallot
> swap ['] <HDtest> each
> .locals
> test-locals negate allot
> ;
>
> \ The following is an example list of people.
>
> nil
> c" aaaaa" new-person link
> c" bbbbb" new-person link
> 3 c" ccccc" new-chick link
> 10 c" Darby" new-chick link
> 8 c" eeeee" new-chick link
> c" fffff" new-person link
> 7 c" ggggg" new-chick link
> 8 c" hhhhh" new-chick link
> constant people
>
>
> This is a test of the code:
>
> try hottie.4th
> Including hottie.4th ok
> people show-seq
> aaaaa
> bbbbb
> ccccc
> Darby
> eeeee
> fffff
> ggggg
> hhhhh
> ok
> people test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
> people macro-test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
> people heap-test
> total people: 8
> total chicks: 5
> level 10 chicks: 1
> level 9 chicks: 0
> level 8 chicks: 2 ok
> people HDtest 8 5 1 0 2 ok
Hi!
> > What is the point of putting your TEST-LOCALS struct in the dictionary rather than the heap? Is that faster?
On heap I have to borrow memory from OS and from here consequences:
CATCH THROW suite to safely release heap to OS when ended the use, etc.
Other possible storage options: dictionary, block buffer, stacks ..
> BTW: Can you think of a good name for the TUCK SWAP stack-juggler? That seems like it should be factored out, but I can't think of a name for it.
I don't either. Maybe better leave it as 2-words sequence like OVER SWAP.
> I am still uncomfortable with using the dictionary rather than the heap. In a simple program like this it will work --- it could get messed up though if sub-functions are also using the dictionary and leaving data there --- this is similar to PAD in that it has reentrancy problems that could bite you.
Yes, there should be such a discipline - a word should not leave data on
dictionary for another word. Just use in local scope.
An alternative is to not de-allot when leaving, and use markers for a bigger
context, something like a session ..
Of course, rquotations have their values.
--
Have a nice day,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | dhoffman888@gmail.com |
|---|---|
| Date | 2016-08-13 04:01 -0700 |
| Message-ID | <82abb01c-a2dc-441f-87ab-d047d1409633@googlegroups.com> |
| In reply to | #49956 |
On Thursday, August 11, 2016 at 3:15:04 PM UTC-4, hughag...@gmail.com wrote:
> > seq
> > w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
> > constant person
> >
> > : init-person ( str node -- node )
> > init-seq >r
> > [char] M r@ .gender ! \ default is male
> > r> ;
> >
> > : new-person ( str -- node )
> > person alloc
> > init-person ;
> >
> > person
> > w field .hotness \ scale of 1 to 10
> > constant chick
> >
> > : init-chick ( hotness str node -- node )
> > init-person >r
> > [char] F r@ .gender !
> > r@ .hotness !
> > r> ;
> >
> > : new-chick ( hotness str -- node )
> > chick alloc
> > init-chick ;
> >
> > : test { head | people chicks tens nines eights -- }
> > head r[
> > 1 +to people
> > dup .gender @ [char] F = if 1 +to chicks
> > .hotness @
> > dup 8 = if 1 +to eights then
> > dup 9 = if 1 +to nines then
> > 10 = if 1 +to tens then \ Yay! We found at least one!
> > else drop then
> > ]r |each
> > cr ." total people: " people .
> > cr ." total chicks: " chicks .
> > cr ." level 10 chicks: " tens .
> > cr ." level 9 chicks: " nines .
> > cr ." level 8 chicks: " eights .
> > ;
> >
> > \ The following is an example list of people.
> >
> > nil
> > c" aaaaa" new-person link
> > c" bbbbb" new-person link
> > 3 c" ccccc" new-chick link
> > 10 c" Darby" new-chick link
> > 8 c" eeeee" new-chick link
> > c" fffff" new-person link
> > 7 c" ggggg" new-chick link
> > 8 c" hhhhh" new-chick link
> > constant people
> >
> >
> > Here is a test of the code:
> >
> > people show-seq
> > aaaaa
> > bbbbb
> > ccccc
> > Darby
> > eeeee
> > fffff
> > ggggg
> > hhhhh
> > ok
> > people test
> > total people: 8
> > total chicks: 5
> > level 10 chicks: 1
> > level 9 chicks: 0
> > level 8 chicks: 2 ok
Another way.
Needs library code located here:
http://soton.mpeforth.com/flag/fms/index.html
( download the FMS-SI.zip Package )
-Doug
include FMS-SI.f
include FMS-SILib.f
:class person <super string
:m init: ( addr len -- ) super init: super !: ;m
;class
:class chick <super person
cell bytes hotness
:m hotness: ( -- n ) hotness @ ;m
:m init: ( hotness addr len -- ) super init: hotness ! ;m
;class
: 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 .
;
object-list people
s" aaaaa" heap> person people add:
s" bbbbb" heap> person people add:
3 s" ccccc" heap> chick people add:
10 s" Darby" heap> chick people add:
8 s" eeeee" heap> chick people add:
s" fffff" heap> person people add:
7 s" ggggg" heap> chick people add:
8 s" hhhhh" heap> chick people add:
:noname cr p: ; people map: \ prints all names
people test
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-13 20:24 -0700 |
| Message-ID | <b646fe6c-da97-401b-a6b4-9eca7c587f4e@googlegroups.com> |
| In reply to | #50030 |
On Saturday, August 13, 2016 at 4:01:31 AM UTC-7, dhoff...@gmail.com wrote: > Needs library code located here: > http://soton.mpeforth.com/flag/fms/index.html > ( download the FMS-SI.zip Package ) 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 convenient, but it is also very inefficient. 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 --- very time-consuming! I would really expect a duck-typing version of the hottie-counting problem to be two orders of magnitude slower than any of the versions I posted. Isn't inefficiency the reason why SmallTalk didn't become popular? OpenForth had duck-typing too, and it didn't become popular either. I really doubt that duck-typing will ever be used outside of scripting languages for which speed is not an issue.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-14 08:22 -0400 |
| Message-ID | <57b0627a$0$292$14726298@news.sunsite.dk> |
| In reply to | #50074 |
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] > I would really expect a duck-typing version of the hottie-counting > problem to be two orders of magnitude slower than any of the versions I > posted. You measured? What was the result? -Doug
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-08-14 07:10 -0700 |
| Message-ID | <40d95309-7256-4c38-9677-22c3b3933dd2@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 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 -- node true | false )
dup 0<> \ -- node flag
dup 0= if nip 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 | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2016-08-14 10:36 -0400 |
| Message-ID | <57b081de$0$292$14726298@news.sunsite.dk> |
| In reply to | #50084 |
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: >> 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: 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. >> "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. My comments stop here. If you don't know what you are talking about it would be better to say nothing. -Doug > 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 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 -- node true | false ) > dup 0<> \ -- node flag > dup 0= if nip 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]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web