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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-08-05 00:42 +0000 |
| Message-ID | <no0ndo$ms7$3@dont-email.me> |
| In reply to | #48804 |
Am Tue, 05 Jul 2016 10:16:10 -0400 schrieb rickman: > Actually, I think it is hard to make a claim that anyone is properly > notified legally by posting a notice in a newsgroup. There is no way to > verify the authenticity of your post or your identity or even that the > notice was ever delivered. Forget about this. German lawyers use printed out screenshots as proof of "using copyrighted pictures on web sites" every day (we have this cease-and-desist industry). I suppose the judges who accept this have never heard of Photoshop. They also use BitTorrent tracker queries as proof, even though these trackers keep old entries for some time when the IP address switched over night, and even though the same anti-piracy industry sets up trackers with huge amounts of fake entries (so they know it is possible to fake it). So don't expect a court to be reasonable. If it's beyond the capability of a judge or a jury to fake a newsgroup posting, for them, it's not possible. Nowadays, with the death of Usenet, the remaining Usenet servers like Google Groups or ethernal september, require registration. So the chance that you can convince a judge that you didn't write this, and it was someone else, is pretty low. Judges hear lame excuses all the time, and they are sick of it. Even if you are right, they won't believe you. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | julian.fondren@endurance.com |
|---|---|
| Date | 2016-08-04 19:44 -0700 |
| Message-ID | <2394ffc5-9d00-4312-b420-6b77a4f61870@googlegroups.com> |
| In reply to | #49797 |
On Thursday, August 4, 2016 at 7:42:33 PM UTC-5, Bernd Paysan wrote: > Am Tue, 05 Jul 2016 10:16:10 -0400 schrieb rickman: > > Actually, I think it is hard to make a claim that anyone is properly > > notified legally by posting a notice in a newsgroup. There is no way to > > verify the authenticity of your post or your identity or even that the > > notice was ever delivered. > > Forget about this. German lawyers use printed out screenshots as proof > of "using copyrighted pictures on web sites" every day (we have this > cease-and-desist industry). I suppose the judges who accept this have > never heard of Photoshop. There's no need to take a screenshot of a webpage and then edit it. Your browser already comes with all you need to study and to edit the DOM itself. So you can put words in anyone's mouth, using their own CSS and in the context of their actual webpage; you can change a tweet to say anything you want and screencap it right on twitter.com; you can add a link to an image or change an existing image link instead. There's still limited awareness of this though (even technical questions about it are mostly people wanting to hide or secure what they've already sent to the browser) so I wouldn't say that you're behind the times. But if you're called to court, you might bring some even more amazingly convincing print-outs. Or your phone, with Tampermonkey and some scripts prepared, so that you can browse to official sites and show your prepared content. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-08-20 22:08 +0000 |
| Message-ID | <npakde$59r$3@dont-email.me> |
| In reply to | #49799 |
Am Thu, 04 Aug 2016 19:44:31 -0700 schrieb julian.fondren:
> There's no need to take a screenshot of a webpage and then edit it. Your
> browser already comes with all you need to study and to edit the DOM
> itself.
Yes, of course. But I think they accept stuff that even someone not
knowing anything about browser technology can use to fake "evidence".
> So you can put words in anyone's mouth, using their own CSS and
> in the context of their actual webpage; you can change a tweet to say
> anything you want and screencap it right on twitter.com; you can add a
> link to an image or change an existing image link instead.
Indeed.
> There's still
> limited awareness of this though (even technical questions about it are
> mostly people wanting to hide or secure what they've already sent to the
> browser) so I wouldn't say that you're behind the times.
Yes, you can, but it's more "complicated" than photoshopping the page, if
the court is in stone-age and wants a printed paper, anyways. Especially
it requires a bit more know-how. Ok, we are talking about jQuery one-
liners like
$('img.fb_logo').attr ('src', "<url>");
(to tamper Facebook's logo in this example), but well... some lawyers
might actually understand that - but only those who need to do other
stuff to make a living ;-).
> But if you're called to court, you might bring some even more amazingly
> convincing print-outs. Or your phone, with Tampermonkey and some
> scripts prepared, so that you can browse to official sites and show your
> prepared content.
Well, these are kangaroo courts with rubber stamps. They normally just
send around paper (no actual hearing), and make sure they don't spend
nearly as much time on the case as you might think. For a "rule of law"
country like Germany, this is a disgrace.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-06 21:01 -0700 |
| Message-ID | <42fca95a-b021-4a83-866f-54cbf8685dfd@googlegroups.com> |
| In reply to | #48645 |
Over on the Forth-200x mailing list, Anton Ertl asks this question:
-------------------------------------------------------------------------
While the discussion of the bike shed proposal is much more intensive
than the nuclear reactor proposal, as usual, I want to draw your
attention to a particular aspect of this nuclear reactor:
> Todo
> ----
>
> The stack effects allow the following:
>
> : foo [: ." a" ; : bar ." b " ;] ;
> foo execute \ prints "a"
> bar \ prints "b"
>
> This actually works in Gforth. Do we want to make this a standard
> program or not? In either case, we need some wording to make our
> intent clear.
I expect that some system implementors speak up if they do not want to
support this kind of usage because it makes the implementation more
complex.
I also expect that programmers speak up if they see a real use for
this kind of feature.
If nobody gives an opinion about this issue, I'll flip a coin.
- anton
-------------------------------------------------------------------------
That is too funny! This reminds me of a book I saw at the bookstore (obviously, didn't buy it): "What if?" (Randall Munroe). This book poses such fascinating questions as: "What would happen if lightning struck a bullet in midair?"
Meanwhile, there appears to be a complete lack of understanding of what quotations do or what they are for. Jennifer Brien says:
-------------------------------------------------------------------------
Since we are in a Hugh-free zone here, can we discuss a little more fully the pros and cons of allowing quotations to access parent locals?
It would seem that the intent of
: bar {: a b :} ... [: ... a b + ... ;] ... ;
could always be provided by
: bar {: a b :} ... a b [: {: c d :} ... c d + ... ;] ... ; although less efficiently.
It might be possible in most cases to avoid the need for locals in the quotation, using stack words instead. If the quotation is used outside the parent, then it only needs the runtime stack to be correct. I'm not sure if Hugh intends his version to be used outside the parent, but the only sensible implementation I can see has these restrictions:
'Local' refers to the most recent local frame no matter how deeply nested, therefore:
A quotation may not declare locals of its own if it refers to parent locals, and
If it is executed outside the parent, it must be within another parent with a compatible local frame.
I don't see how this could be useful, but maybe I'm missing something. What?
-------------------------------------------------------------------------
I have explained this a dozen times or more, but apparently she missed all of these explanations. This is not complicated folks! Gavino's attention-span is about 2 minutes --- if you have an attention-span twice as long, you should be able to come to grips with how quotations work --- focus!
No, the quotation can not have locals of is own --- if it needs locals, they need to be defined in the parent function (this is rare because quotations are typically one-liners that are too simple to need to store intermediate values anywhere other than the data-stack) --- accessing the parent function's locals is primarily useful for allowing the quotation to up-feed information to the parent function.
Earlier in this thread I said:
-------------------------------------------------------------------------
On Friday, July 1, 2016 at 5:57:19 PM UTC-7, hughag...@gmail.com wrote:
> Straight Forth has a 64-bit cell, but has 32-bit addresses. This means that there is plenty of room in an xt for both the 32-bit cfa of the quotation and the 32-bit pointer to the parent function's local-frame. This is not "relatively complex" nor does it "impose a run-time overhead" --- this is super-simple!
>
> In the meantime, we have the LFT (local-fall-through) method that can be used in various ANS-Forth systems (it is not ANS-Forth compliant however).
>
> HumptyDumpty wrote this code for gForth:
>
> : rexit ( -- ) RDROP ;
> : (r:) ( -- r ) R@ 0 ;
> : r[ ( -- r ) postpone (r:) postpone IF ; immediate
> : ]r ( -- ) postpone REXIT postpone THEN ; immediate
> : rex ( r -- ) >R -1 ; \ HumptyDumpty called this RCALL
>
> I modified it slightly for VFX:
>
> : rexit ( -- ) rdrop ;
> : (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
> : r[ ( -- r ) postpone (r:) postpone ahead ; immediate
> : ]r ( -- ) postpone rexit postpone then ; immediate
>
> code rex ( r -- ) \ HumptyDumpty called this RCALL
> push edi \ this is the HOF's LF which won't be used by the quotation
> mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
> call ' execute
> pop edi \ restore HOF's LF
> next, end-code
>
> My version allows the HOF to have local variables (in HumptyDumpty's version the HOF was not allowed to have local variables). The rules are:
> 1.) The HOF must have local variables (not optional).
> 2.) REX is used to execute a quotation and can only be used inside of a HOF.
> 3.) A HOF can not call another HOF directly.
>
> The purpose of quotations is to allow Forth to have general-purpose data-structures. Typically there will be a HOF provided that traverses the data-structure and executes a quotation for every node in the data-structure. The parent function defines a quotation and then calls the HOF giving the HOF the quotation xt as a parameter. The HOF executes the quotation for each struct in the data-structure, giving the quotation the address of the struct as a parameter. The quotation communicates information back to the parent function by storing this data in the parent function's locals.
>
> Here is an example of a singly-linked-list:
>
> 0
> w field .fore \ .FORE will be fast because it is in the front
> constant list
>
> Here is a HOF for the LIST data-structure:
>
> : each { head 'quotation -- }
> head begin dup while
> dup .fore @ >r \ -- node \ return: -- next-node
> 'quotation rex \ -- \ the quotation consumes the node adr
> r> repeat drop ;
>
> This is very similar to EACH that I have in the novice-package. The difference being that here the quotation has access to the locals in the parent function. In the novice-package, there were no quotations --- the xt being passed in was either of a colon word or of a :NONAME word --- it had to communicate back to the parent function by modifying the data on the data-stack put there by the parent function prior to calling EACH.
>
> The Paysan-faked quotations which are promoted in Anton Ertl's RfD (formerly Alex McDonald's RfD) work exactly the same way as what I have in the novice-package already --- they are just syntactic sugar --- they provide no features that I'm not already providing in the novice-package (the novice-package is written in ANS-Forth as are the Paysan-faked quotations).
-------------------------------------------------------------------------
I really don't want to be a part of Forth-200x! Idiots! They really don't understand the basics of computer programming --- they are the worst possible candidates for setting the Standard for Forth --- there is no hope that Forth-200x will have any more value in the real-world than ANS-Forth did, which is zero, although I'm expecting Forth-200x when finally ratified to be an order of magnitude larger than ANS-Forth.
I would expect Straight Forth to be less than half the size of ANS-Forth --- and, as a bonus, it would be useful in the real-world --- why are people opposed to this???
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-07-07 07:54 +0000 |
| Message-ID | <nll1qr$453$1@dont-email.me> |
| In reply to | #48862 |
hughaguilar96@gmail.com wrote: > The purpose of quotations is to allow Forth to have > general-purpose data-structures. Typically there will > be a HOF provided that traverses the data-structure and > executes a quotation for every node in the > data-structure. The parent function defines a quotation > and then calls the HOF giving the HOF the quotation xt > as a parameter. The HOF executes the quotation for each > struct in the data-structure, giving the quotation the > address of the struct as a parameter. The quotation > communicates information back to the parent function by > storing this data in the parent function's locals. The anonymous function, closure, or lambda doesn't have to alter the parent function's local variables; it may merely read those variables. OCaml: let mul_list x list = List.map (fun y -> x*y) list ;; mul_list 200 [3;4;5;6;7;8;9] ;; ===> [600; 800; 1000; 1200; 1400; 1600; 1800] Shorter: let mul_list x = List.map (( * ) x) ;; mul_list 200 [3;4;5;6;7;8;9] ;; ===> [600; 800; 1000; 1200; 1400; 1600; 1800] -- I don't believe in western morality, i.e. don't kill civilians or children.... The only way to fight a moral war is the Jewish way: Destroy their holy sites. Kill men, women and children (and cattle). --- Rabbi Manis Friedman web.archive.org/web/20090605154706/http://www.momentmag.com/Exclusive/2009/2009-06/200906-Ask_Rabbis.html archive.org/download/DavidDukeVideo/TheZionistMatrixOfPowerddhd.ogv
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-08 08:17 -0700 |
| Message-ID | <c18c7492-7b26-49c6-8453-183156e4ad37@googlegroups.com> |
| In reply to | #48862 |
On Wednesday, July 6, 2016 at 9:01:34 PM UTC-7, hughag...@gmail.com wrote:
> ...there appears to be a complete lack of understanding of what quotations do or what they are for. Jennifer Brien says:
> -------------------------------------------------------------------------
> Since we are in a Hugh-free zone here, can we discuss a little more fully the pros and cons of allowing quotations to access parent locals?
>
> It would seem that the intent of
>
> : bar {: a b :} ... [: ... a b + ... ;] ... ;
>
> could always be provided by
>
> : bar {: a b :} ... a b [: {: c d :} ... c d + ... ;] ... ; although less efficiently.
>
> It might be possible in most cases to avoid the need for locals in the quotation, using stack words instead. If the quotation is used outside the parent, then it only needs the runtime stack to be correct. I'm not sure if Hugh intends his version to be used outside the parent, but the only sensible implementation I can see has these restrictions:
>
> 'Local' refers to the most recent local frame no matter how deeply nested, therefore:
> A quotation may not declare locals of its own if it refers to parent locals, and
> If it is executed outside the parent, it must be within another parent with a compatible local frame.
>
> I don't see how this could be useful, but maybe I'm missing something. What?
> -------------------------------------------------------------------------
>
> I have explained this a dozen times or more, but apparently she missed all of these explanations. This is not complicated folks! Gavino's attention-span is about 2 minutes --- if you have an attention-span twice as long, you should be able to come to grips with how quotations work --- focus!
>
> No, the quotation can not have locals of is own --- if it needs locals, they need to be defined in the parent function (this is rare because quotations are typically one-liners that are too simple to need to store intermediate values anywhere other than the data-stack) --- accessing the parent function's locals is primarily useful for allowing the quotation to up-feed information to the parent function.
>
> Earlier in this thread I said:
> -------------------------------------------------------------------------
> On Friday, July 1, 2016 at 5:57:19 PM UTC-7, hughag...@gmail.com wrote:
> > Straight Forth has a 64-bit cell, but has 32-bit addresses. This means that there is plenty of room in an xt for both the 32-bit cfa of the quotation and the 32-bit pointer to the parent function's local-frame. This is not "relatively complex" nor does it "impose a run-time overhead" --- this is super-simple!
> >
> > In the meantime, we have the LFT (local-fall-through) method that can be used in various ANS-Forth systems (it is not ANS-Forth compliant however).
> >
> > HumptyDumpty wrote this code for gForth:
> >
> > : rexit ( -- ) RDROP ;
> > : (r:) ( -- r ) R@ 0 ;
> > : r[ ( -- r ) postpone (r:) postpone IF ; immediate
> > : ]r ( -- ) postpone REXIT postpone THEN ; immediate
> > : rex ( r -- ) >R -1 ; \ HumptyDumpty called this RCALL
> >
> > I modified it slightly for VFX:
> >
> > : rexit ( -- ) rdrop ;
> > : (r:) ( -- r ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
> > : r[ ( -- r ) postpone (r:) postpone ahead ; immediate
> > : ]r ( -- ) postpone rexit postpone then ; immediate
> >
> > code rex ( r -- ) \ HumptyDumpty called this RCALL
> > push edi \ this is the HOF's LF which won't be used by the quotation
> > mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
> > call ' execute
> > pop edi \ restore HOF's LF
> > next, end-code
> >
> > My version allows the HOF to have local variables (in HumptyDumpty's version the HOF was not allowed to have local variables). The rules are:
> > 1.) The HOF must have local variables (not optional).
> > 2.) REX is used to execute a quotation and can only be used inside of a HOF.
> > 3.) A HOF can not call another HOF directly.
> >
> > The purpose of quotations is to allow Forth to have general-purpose data-structures. Typically there will be a HOF provided that traverses the data-structure and executes a quotation for every node in the data-structure. The parent function defines a quotation and then calls the HOF giving the HOF the quotation xt as a parameter. The HOF executes the quotation for each struct in the data-structure, giving the quotation the address of the struct as a parameter. The quotation communicates information back to the parent function by storing this data in the parent function's locals.
> >
> > Here is an example of a singly-linked-list:
> >
> > 0
> > w field .fore \ .FORE will be fast because it is in the front
> > constant list
> >
> > Here is a HOF for the LIST data-structure:
> >
> > : each { head 'quotation -- }
> > head begin dup while
> > dup .fore @ >r \ -- node \ return: -- next-node
> > 'quotation rex \ -- \ the quotation consumes the node adr
> > r> repeat drop ;
> >
> > This is very similar to EACH that I have in the novice-package. The difference being that here the quotation has access to the locals in the parent function. In the novice-package, there were no quotations --- the xt being passed in was either of a colon word or of a :NONAME word --- it had to communicate back to the parent function by modifying the data on the data-stack put there by the parent function prior to calling EACH.
> >
> > The Paysan-faked quotations which are promoted in Anton Ertl's RfD (formerly Alex McDonald's RfD) work exactly the same way as what I have in the novice-package already --- they are just syntactic sugar --- they provide no features that I'm not already providing in the novice-package (the novice-package is written in ANS-Forth as are the Paysan-faked quotations).
> -------------------------------------------------------------------------
Meanwhile, the "Hugh-free zone" continues to a knowledge-free zone as well:
On Thursday, July 7, 2016 11:37 AM, "Jennifer Brien jennybrien@googlemail.com [forth200x]" <forth200x@yahoogroups.com> wrote:
|On Thu, Jul 7, 2016 at 3:48 PM, Hans Bezemer hansoft@xs4all.nl [forth200x] <forth200x@yahoogroups.com> wrote:
||I don't like to write dirty stuff just to please quiche eaters, so IMHO this
||one is far more controversial that the "keep access to outer variables". For
||what? It has already executed. The thing is dead!
|I think we are all agreed on that. I asked because I didn't see any great
|need for what Hugh was demanding, I still don't, and I can see trying to
|provide it might result in a lot of gotchas. I'm quite content with what he
|is pleased to call "Paysan faked quotations."
|As far as locals and quotations are concerned, I think it is much more
|important that they can be passed as parameters to structure-walking words
|like map-array and traverse-wordlist.
I read through Bezemer's full post and I didn't understand what he was talking about. He mentions "quiche eaters" apparently meaning me, and he describes quotations that can access the parent function's locals as being "fluffy." It all seemed like pseudo-intellectual blather to me, but apparently Jennifer Brien understood it and agreed with it.
What she describes as "structure-walking words" are called HOFs (higher-order functions). She apparently doesn't know the term HOF. Also, she seems to believe that I'm arguing against allowing for the quotation xt to be passed into the HOF as a parameter. This is actually the whole point of the exercise though! I'm arguing that the quotations, when it is executed inside of the HOF, should have access not only to the data-stack but also to the parent-function's locals. She said earlier: "I'm not sure if Hugh intends his version to be used outside the parent."
Anyway, as I said earlier, the Paysan-faked quotations were pre-approved by Leon Wagner. The RfD was guaranteed to get accepted into Forth-200x from the get-go, so there was never any point in arguing against it --- the smart thing for the Forth-200x mailing-list crowd to do is to just find out what Leon Wagner wants and then argue in favor of that --- as for alternative ideas, these can all be dismissed with specious arguments, and there is no need to actually understand the alternative ideas.
I don't think anybody on the Forth-200x committee or mailing list knows anything about the subject that they are discussing --- it is not my job to teach a programming-101 class to people who have already claimed to be qualified to set the Standard for the entire Forth community --- I think Forth-200x can be discarded as worthless; it is a house built by idiots (for bedrock they used sand and for mortar they used bullshit).
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-08 08:41 -0700 |
| Message-ID | <edd062cd-d431-4362-88c7-44b062291902@googlegroups.com> |
| In reply to | #48960 |
On Friday, July 8, 2016 at 8:17:24 AM UTC-7, hughag...@gmail.com wrote: > What she describes as "structure-walking words" are called HOFs (higher-order functions). She apparently doesn't know the term HOF. Also, she seems to believe that I'm arguing against allowing for the quotation xt to be passed into the HOF as a parameter. This is actually the whole point of the exercise though! I'm arguing that the quotations, when it is executed inside of the HOF, should have access not only to the data-stack but also to the parent-function's locals. She said earlier: "I'm not sure if Hugh intends his version to be used outside the parent." This stuff just goes on-and-on. About a year ago I invented the FMITE processor (later upgraded substantially and the name changed to Stundurd). The primary feature here was quotations that could access the parent function's locals when they were executed within a HOF called by the parent function. Here is a post about it: On Sunday, July 5, 2015 at 2:36:05 AM UTC-7, Alex McDonald wrote: > Then, as Hugh complains about Bernd's "faked quotations", his FMITE is no > more than :NONAME syntactic sugar. Perhaps worse, as from what I read > there the language does not permit use of the quotation outside of its > enclosing word. The ANS-Forth and Forth-200x committees endlessly project their own ignorance onto the rest of the Forth community, and then call this the Standard. Here a post from Elizabeth Rather on the subject (this was discussing my novice-package implementation): ------------------------------------------------------------------------ Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure. ------------------------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2016-07-08 10:21 -0700 |
| Message-ID | <6f58183e-27d6-4389-b2f9-07ea13916a30@googlegroups.com> |
| In reply to | #48964 |
On Friday, July 8, 2016 at 10:41:49 AM UTC-5, hughag...@gmail.com wrote: (quoting Rather) > Does "*every* application" you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your "general-purpose" structure. thedailywtf.com came up with an antipattern called the Inner-Platform Effect: http://thedailywtf.com/articles/The_Inner-Platform_Effect I've seen this in practice. We needed a new ticketing system - basically just web forms that would guide support technicians' creation of tickets, instead of letting them just type anything they wanted into a textbox. Dev could've done the boring and straightforward thing: find out what forms we need, and then make those forms. As we ran into deficiencies with the forms, or ways to improve the workflow, we would then go back to Dev and they could then code those improvements, and so on. This kind of interaction requires a lot of contact, a lot of back and forth. For it to work well, it requires that Dev go to some effort to understand how their product will actually be used, and it can require that customers come to some understand about what's reasonable and possible to want out of the product vs. what is asking for a pony. But by having the shortest path between the people who use the system and the people who develop the system (normal path: dev<->management, closed circuit, users can complain after mistakes are good and rooted into the architecture), you can have data entry that is not quite as menial and boring and painful as it generally is. It is actually possible for odd data-entry needs to *not* feel like you have "Data Entry Clerk" as an unpaid part-time job, in addition to your real job. I promise you, it's true. (Although I've only seen that after copious application of GreaseMonkey.) So naturally this happened instead: Dev went deep into a cave, and worked for a long time, and finally brought out a ticketing system that would cut right through the Dev<->Us contact loop! Yes, it's a ticketing system so flexible and amazing that a developer is no longer required for a web form to be built. You can just get low-level management to put all of the forms together -- the guys supervising the guys who will use it. Perfect! Do you have to write HTML? Hell no! That stuff's hard! Do you have to write JavaScript or CSS? Of couse not! You have a very nice WYSIWYG system and anyone can put forms together and ticket-creation webforms are a solved problem forever more. The system is so flexible. It is so flexible that my first greasemonkey script for it, one to make it slightly less suicide-encouragingly painful to create a certain kind of common ticket, required use of a MutationObserver. The only way I could deal with this thing was to watch literally every single DOM mutation made by JavaScript, until I saw a mutation I sort of recognized, so that I could leap and in say "wait wait wait, do this too!". That's just the user side. The management side, the web form creation side, was agonizing as well. When management did something wrong while creating a form, because the mechanics were so opaque, basically all they could do was throw the entire form away. They had to start over again from the beginning, before whatever introduced the error. The effort of creating a new form, almost but not quite like another existing form, far exceeded the effort of the same task using with a straightforward system. Anyway, back to Forth. What do you do if you want to handle some data, in Forth? You come up with an appropriate data structure and implement words that work with it. OK, that's primitive. Only a 'non-programmer' would just go ahead and program things in a direct manner like that. So let's add a bunch of high-level data structures. RFC: let's put the entirety of FFL into Forth 200x. Why not? Once that's done, when you want to handle some data in Forth, what do you do? Well, you come up with an appropriate data structure and implement words that work with it. Wait, that's the same thing. That can't be right. OK, clearly, *Forth itself* is in the wrong. You shouldn't be tempted to create your appropriate words. What do people do in other languages, where they have syntax and can access data the same way all the time (unless it's in a database or in a file or hiding behind a service of some kind)? Well, speaking as someone who writes a lot of code in non-Forth languages, I can tell you that I'm always thinking of appropriate data structures and then writing functions that work with them. Just the other day I wrote used Class::Struct in Perl, and then a serializer that turned it into JSON, and I had multiple flat files that had to be parsed into it. And then I dealt with these Class::Struct objects in an object-oriented way, I didn't actually directly use Perl's high-level data structures at this point. That might *sound* very much like the original statement about Forth above, but it's totally different, see, because all of my get_this_field() and set_that_field() methods had *syntax* in them instead of cumbersome Forth words like @ ! + ETC -- Julian
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2016-07-08 14:29 -0700 |
| Message-ID | <a400b1f3-d861-4462-b284-b0572eec0b5f@googlegroups.com> |
| In reply to | #48862 |
On Thursday, 7 July 2016 05:01:34 UTC+1, hughag...@gmail.com wrote:
> Over on the Forth-200x mailing list, Anton Ertl asks this question:
> Meanwhile, there appears to be a complete lack of understanding of what quotations do or what they are for. Jennifer Brien says:
> -------------------------------------------------------------------------
> Since we are in a Hugh-free zone here, can we discuss a little more fully the pros and cons of allowing quotations to access parent locals?
>
> It would seem that the intent of
>
> : bar {: a b :} ... [: ... a b + ... ;] ... ;
>
> could always be provided by
>
> : bar {: a b :} ... a b [: {: c d :} ... c d + ... ;] ... ; although less efficiently.
>
> It might be possible in most cases to avoid the need for locals in the quotation, using stack words instead. If the quotation is used outside the parent, then it only needs the runtime stack to be correct. I'm not sure if Hugh intends his version to be used outside the parent, but the only sensible implementation I can see has these restrictions:
>
> 'Local' refers to the most recent local frame no matter how deeply nested, therefore:
> A quotation may not declare locals of its own if it refers to parent locals, and
> If it is executed outside the parent, it must be within another parent with a compatible local frame.
>
> I don't see how this could be useful, but maybe I'm missing something. What?
> -------------------------------------------------------------------------
>
> No, the quotation can not have locals of is own --- if it needs locals, they need to be defined in the parent function (this is rare because quotations are typically one-liners that are too simple to need to store intermediate values anywhere other than the data-stack) --- accessing the parent function's locals is primarily useful for allowing the quotation to up-feed information to the parent function.
Locals declared within a quotation seem to be a bit like male nipples - not much use in any normal circumstances, but they are a natural consequence of the body plan. In this case they are possible because quotations use the same colon-sys as definitions and :nonames. Why should they not? It's easieer to implement and specify their behaviour that way.
I must admit that I haven't done much in Forth for more years than I care to remember, and I'm not used to locals, so sometimes I make mistakes. Anton pointed out that the example I gave above was flawed in the case where the quotation would be executed multiple times by a HOF, because it takes data from the stack at each execution.
Sometimes quotations are executed outside the scope of their parent word, for example to provide behaviour for Deferred words. In this use they provide all the functionality of Brodie's Doer/Make construction. Naturally, there is normally is no sense in trying to access parent locals in that situation, when the parent is no longer in scope. I noted that IF parent locals were accessible, then they might still make sense outside the parent IF they were executed within another word with the same local signature. I couldn't see a practical use for that, and Hans rightly declared the idea was "fluffy."
>
> Earlier in this thread I said:
> -------------------------------------------------------------------------
> On Friday, July 1, 2016 at 5:57:19 PM UTC-7, hughag...@gmail.com wrote:
> > Straight Forth has a 64-bit cell, but has 32-bit addresses. This means that there is plenty of room in an xt for both the 32-bit cfa of the quotation and the 32-bit pointer to the parent function's local-frame. This is not "relatively complex" nor does it "impose a run-time overhead" --- this is super-simple!
Maybe so, and if the Standard specifies "Paysan Faked Quotations" (PFQs) a Forth implementer may choose that or any other method to allows AQs (Aguilar's Quotations) and still be Standard compliant. If enough decide to do that, then perhaps the will be extended to include AQs
> >
> > In the meantime, we have the LFT (local-fall-through) method that can be used in various ANS-Forth systems (it is not ANS-Forth compliant however).
The question is - whether AQs are valuable enough for implementers of existing Forths to upgrade their implementation of local variables, and perhaps break existing non-Standard code that depends on carnal knowledge of how locals work.
> > My version allows the HOF to have local variables (in HumptyDumpty's version the HOF was not allowed to have local variables). The rules are:
> > 1.) The HOF must have local variables (not optional).
> > 2.) REX is used to execute a quotation and can only be used inside of a HOF.
> > 3.) A HOF can not call another HOF directly.
Hmmm,
1.} seems sensible, for a HOF probably uses a local to hold the quotation xt. But how can you be sure of that? It seems HUmptyDumpty can write HOFs without using locals.
2.) Makes a difference in syntax between AQs and PFQs. Or rather, since every HOF has to call Rex (since it might be passed an AQ) there is an overhead every time it is passed a PFQ, Maybe not too important.
3.) Are you sure no one will ever want to use a HOF in the definition of another HOF, and that if they do, they will remember this rule and why it is? I understand why it is so: Rex skips exactly one level of locals (which is why the HOF must have locals, simply so they can be ignored.) That seems very fragile and un-Forthlike to me.
In short, an efficient Rex to accommodate AQs requires rules 1 and 3. Relaxing them means even more overhead.
What does this gain you? As you said, quotations are normally one-liners and don't need the overhead of their own locals. Typically they mutate or consume a single value provided on the top of the stack by the HOF. Any other parameter the HOF (not the quotation) needs are probably held internally off the stack as locals. So why not just pass anything extra needed from the parent on the stack?
: FOO {: a b :} ... [: a b bar :] each ;
is
: FOO {: a b :} ... a b [: 2DUP bar :] each 2DROP ;
Worth the difference, or just one more step to a fatter Forth?
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-08 22:28 -0700 |
| Message-ID | <972fd5fb-43a2-4ccb-994d-96ea4f3e878a@googlegroups.com> |
| In reply to | #48969 |
On Friday, July 8, 2016 at 2:29:45 PM UTC-7, JennyB wrote:
> On Thursday, 7 July 2016 05:01:34 UTC+1, hughag...@gmail.com wrote:
> > On Friday, July 1, 2016 at 5:57:19 PM UTC-7, hughag...@gmail.com wrote:
> > > Straight Forth has a 64-bit cell, but has 32-bit addresses. This means that there is plenty of room in an xt for both the 32-bit cfa of the quotation and the 32-bit pointer to the parent function's local-frame. This is not "relatively complex" nor does it "impose a run-time overhead" --- this is super-simple!
>
> Maybe so, and if the Standard specifies "Paysan Faked Quotations" (PFQs) a Forth implementer may choose that or any other method to allows AQs (Aguilar's Quotations) and still be Standard compliant. If enough decide to do that, then perhaps the will be extended to include AQs
Straight Forth and ANS-Forth are not compatible. You can't have a fat-xt in ANS-Forth or Forth-200x.
> > > In the meantime, we have the LFT (local-fall-through) method that can be used in various ANS-Forth systems (it is not ANS-Forth compliant however).
>
> The question is - whether AQs are valuable enough for implementers of existing Forths to upgrade their implementation of local variables, and perhaps break existing non-Standard code that depends on carnal knowledge of how locals work.
Upgrade their implementation of local variables? What???
My code works find under VFX --- I didn't have to upgrade the VFX implementation of local variables.
I looked at SwiftForth and it uses ESI instead of EDI --- I could write my code for SwiftForth too --- I haven't bothered with this yet, so I don't know for sure that it can be done, but it appears to be trivial.
HumptyDumpty's code works under either VFX or SwiftForth as is --- gForth too, according to HumptyDumpty, although I haven't tested this myself.
All in all, getting the LFT method to work under any existing ANS-Forth compiler should be trivial.
> > > My version allows the HOF to have local variables (in HumptyDumpty's version the HOF was not allowed to have local variables). The rules are:
> > > 1.) The HOF must have local variables (not optional).
> > > 2.) REX is used to execute a quotation and can only be used inside of a HOF.
> > > 3.) A HOF can not call another HOF directly.
>
> Hmmm,
>
> 1.} seems sensible, for a HOF probably uses a local to hold the quotation xt. But how can you be sure of that? It seems HUmptyDumpty can write HOFs without using locals.
> 2.) Makes a difference in syntax between AQs and PFQs. Or rather, since every HOF has to call Rex (since it might be passed an AQ) there is an overhead every time it is passed a PFQ, Maybe not too important.
> 3.) Are you sure no one will ever want to use a HOF in the definition of another HOF, and that if they do, they will remember this rule and why it is? I understand why it is so: Rex skips exactly one level of locals (which is why the HOF must have locals, simply so they can be ignored.) That seems very fragile and un-Forthlike to me.
HumptyDumpty's version requires the HOF to not have local variables, whereas mine requires the HOF to have local variables --- either way the LFT method has a strict requirement --- my requirement is better because you get locals that you wouldn't get otherwise (holding the quotation xt in a local always simplifies the code, as compared to the alternative which is to hold it on the return-stack).
> In short, an efficient Rex to accommodate AQs requires rules 1 and 3. Relaxing them means even more overhead.
What??? I think you said this backwards --- my REX is slightly more complicated than HumptyDumpty's so there is slightly more overhead with my method --- I don't think this is going to have any significant effect on program speed.
This is my REX function:
code rex ( r -- ) \ HumptyDumpty called this RCALL
push edi \ this is the HOF's LF which won't be used by the quotation
mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
call ' execute
pop edi \ restore HOF's LF
next, end-code
HumptyDumpty's REX is basically just EXECUTE --- so I have 3 extra instructions (REX could be inlined rather than be a function, in which case there would be 3 instructions beyond the CALL to EXECUTE).
> What does this gain you? As you said, quotations are normally one-liners and don't need the overhead of their own locals. Typically they mutate or consume a single value provided on the top of the stack by the HOF. Any other parameter the HOF (not the quotation) needs are probably held internally off the stack as locals. So why not just pass anything extra needed from the parent on the stack?
>
> : FOO {: a b :} ... [: a b bar :] each ;
>
> is
>
> : FOO {: a b :} ... a b [: 2DUP bar :] each 2DROP ;
>
> Worth the difference, or just one more step to a fatter Forth?
You are totally not understanding the purpose of allowing the quotation to access the parent function's locals --- the purpose is so the quotation can upfeed data to the parent --- you're assuming that the purpose is to pass data from the parent to the quotation.
Another thing you don't understand is that I'm not arguing for changes to be made to Forth-200x --- I consider Forth-200x to be worthless; also, I am aware that the RfD has been pre-approved by Leon Wagner and is guaranteed to be accepted, so arguing against it is waste of time --- I'm just pointing out that the LFT method can be made to work in a non-standard way in most existing ANS-Forth systems as a stop-gap until Straight Forth is available.
My LFT code works fine in VFX right now --- Stephen Pelc is going to look foolish supporting Forth-200x with its Paysan-faked quotations when I am simultaneously using LFT quotations in VFX --- it will become obvious that he is purposely crippling Forth-200x so it doesn't have features that VFX has (in this case I implemented the features, although usually it is Pelc himself who implemented the features).
This is my point. ANS-Forth and Forth-200x are crippleware --- they were designed specifically to prevent Forth programmers from having useful features --- this was done to induce the Forth programmers to buy commercial Forth compilers that are non-standard and trap them in vendor lock-in.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2016-07-09 03:56 -0700 |
| Message-ID | <bf24fa61-c175-4baf-bb6d-e653d109cf05@googlegroups.com> |
| In reply to | #48974 |
On Saturday, 9 July 2016 06:28:27 UTC+1, hughag...@gmail.com wrote: > On Friday, July 8, 2016 at 2:29:45 PM UTC-7, JennyB wrote: > > On Thursday, 7 July 2016 05:01:34 UTC+1, hughag...@gmail.com wrote: > > > On Friday, July 1, 2016 at 5:57:19 PM UTC-7, hughag...@gmail.com wrote: > > > > Straight Forth has a 64-bit cell, but has 32-bit addresses. This means that there is plenty of room in an xt for both the 32-bit cfa of the quotation and the 32-bit pointer to the parent function's local-frame. This is not "relatively complex" nor does it "impose a run-time overhead" --- this is super-simple! > > > > Maybe so, and if the Standard specifies "Paysan Faked Quotations" (PFQs) a Forth implementer may choose that or any other method to allows AQs (Aguilar's Quotations) and still be Standard compliant. If enough decide to do that, then perhaps the will be extended to include AQs > > Straight Forth and ANS-Forth are not compatible. You can't have a fat-xt in ANS-Forth or Forth-200x. VFX has a 'fat xt' that allows its compiling behaviour to be found from the xt alone. You can't take advantage of that is Standard code, but that's a different matter. All the Standard does is allow you to know whether particular source code can run on your system without having to go through it line-by-line. A system does not have to implement all the Standard wordsets, nor need its own source code confine itself to words that can be defined in the Standard. Straight Forth will be under the same constraints. You need to define its interface with the hardware it runs on very carefully. Once code has been released that adheres to the published standard. it must continue to work on different hardware as that standard evolves. So far, I have seen a number of statements from you to the effect that "it would be trivial to implement that on Straight Forth - I may or I may not." It's trivial to do *anything* given a clean sheet of paper, but as Chuck used to say, you can't do *everything*. You have to pick and choose. You've chosen, it seems, for Straight Forth to support only 64-bit processors (a 64-bit stack will be costly on anything less) That's fine, your choice. What other assumptions have you made about its requirements? Which of the ANS wordsets will it not be possible to write in Straight Forth? > > > > > In the meantime, we have the LFT (local-fall-through) method that can be used in various ANS-Forth systems (it is not ANS-Forth compliant however). > > > > The question is - whether AQs are valuable enough for implementers of existing Forths to upgrade their implementation of local variables, and perhaps break existing non-Standard code that depends on carnal knowledge of how locals work. > > Upgrade their implementation of local variables? What??? My mistake. I thought maybe there would be some local implementations where the parent locals were not easily accessible - but the system has to know where they are anyway to restore them, so it should be trivial to write for any given system, given the restrictions you set. You have to make the case though, that its worth doing. I haven't seen any application code that needs this, and apparently there is no existing practice of using AQs in any existing Forth system. Can you point to some application code that would be Standard compliant apart from the fact that it uses this construct, and demonstrate that it is faster, or clearer? > > You are totally not understanding the purpose of allowing the quotation to access the parent function's locals --- the purpose is so the quotation can upfeed data to the parent --- you're assuming that the purpose is to pass data from the parent to the quotation. OK, show me an example of that. > > Another thing you don't understand is that I'm not arguing for changes to be made to Forth-200x --- I consider Forth-200x to be worthless; also, I am aware that the RfD has been pre-approved by Leon Wagner and is guaranteed to be accepted, so arguing against it is waste of time --- I'm just pointing out that the LFT method can be made to work in a non-standard way in most existing ANS-Forth systems as a stop-gap until Straight Forth is available. I understand that. I don't understand why, in that case, you are lurking on the Forth 200x mailing list. > This is my point. ANS-Forth and Forth-200x are crippleware --- they were designed specifically to prevent Forth programmers from having useful features --- this was done to induce the Forth programmers to buy commercial Forth compilers that are non-standard and trap them in vendor lock-in. ANS-Forth and Forth-200x are not software of any kind. They are source code publication standards. If you want to write code that other systems can run, or run code that other people have written, then it's a good idea for your Forth to understand Standard code. That doesn't mean your system has to be limited to what the Standard covers. Go ahead and implement AQs or whatever else your heart desires in whatever way you wish. If the commercial compilers already provide it, you may find it more sensible to buy one of those. That, again is your choice. Even if there was a Standard tailored exactly to your needs you would still have to buy a compiler, write your own, or pay someone to do it for you. What you can't expect is for people to change the inner workings of their systems (maybe breaking code of their own) just so they can run your source code, especially if your code has no proven history of use. That is precisely why Standards take so long to evolve.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-09 09:51 -0700 |
| Message-ID | <09c67814-961b-4408-8e80-005e36b559fb@googlegroups.com> |
| In reply to | #48981 |
On Saturday, July 9, 2016 at 3:56:08 AM UTC-7, JennyB wrote: > On Saturday, 9 July 2016 06:28:27 UTC+1, hughag...@gmail.com wrote: > > Straight Forth and ANS-Forth are not compatible. You can't have a fat-xt in ANS-Forth or Forth-200x. > > VFX has a 'fat xt' that allows its compiling behaviour to be found from the xt alone. No it doesn't! This is EXECUTE in VFX: see execute EXECUTE ( 0040965C 53 ) PUSH EBX ( 0040965D 8B5D00 ) MOV EBX, [EBP] ( 00409660 8D6D04 ) LEA EBP, [EBP+04] ( 00409663 C3 ) NEXT, ( 8 bytes, 4 instructions ) ok The xt in VFX is just the CFA. The fat-xt in Straight Forth is a struct containing two fields --- the 32-bit CFA and the 32-bit pointer to the parent function's local-frame. > You've chosen, it seems, for Straight Forth to support only 64-bit processors (a 64-bit stack will be costly on anything less) That's fine, your choice. What other assumptions have you made about its requirements? There are two versions of Straight Forth: 1.) the Fixed Version that has a 64-bit cell and numbers are fixed-point with an assumed unity of 2^32 2.) the Float Version that has a 64-bit cell and numbers are IEEE-754 floats. Most implementations will use the Fixed Version and this will be a natural fit for 64-bit processors (essentially all laptop and desktop computers sold today are 64-bit x86; I don't think you can even buy 32-bit x86 except used). If you have a 32-bit computer and you want to run Straight Forth, you would be best off to go with the Float Version --- if you have a numeric coprocessor to do IEEE-754 then your code should be acceptably fast, and as a bonus you get a gigantic range of values as compared to the Fixed Version --- if you have a 32-bit computer and no numeric coprocessor, then you are in trouble (just donate it to the thrift store and buy something built this century). > Which of the ANS wordsets will it not be possible to write in Straight Forth? There are only a tiny handful of wordsets in ANS-Forth and all of them are trivial. > > > The question is - whether AQs are valuable enough for implementers of existing Forths to upgrade their implementation of local variables, and perhaps break existing non-Standard code that depends on carnal knowledge of how locals work. > > > > Upgrade their implementation of local variables? What??? > > My mistake. I thought maybe there would be some local implementations where the parent locals were not easily accessible - but the system has to know where they are anyway to restore them, so it should be trivial to write for any given system, given the restrictions you set. It is theoretically possible to have an ANS-Forth system for which the LFT method won't work. Any system that holds all of its locals in registers would be problematic --- this would require tweaking the compiler itself --- add-on code such as I wrote above won't work. There aren't any such systems though! ANS-Forth requires a minimum of 8 locals, and the 32-bit x86 doesn't have enough registers to hold 8 locals in registers. This might become an issue if either VFX or SwiftForth someday get upgraded to 64-bit --- but they would be better off to just upgrade from ANS-Forth to Straight Forth if they are going to upgrade from 32-bit to 64-bit. > You have to make the case though, that its worth doing. I haven't seen any application code that needs this, and apparently there is no existing practice of using AQs in any existing Forth system. > > Can you point to some application code that would be Standard compliant apart from the fact that it uses this construct, and demonstrate that it is faster, or clearer? All the modern languages have this feature --- look at any professional program written during the 21st Century. > > Another thing you don't understand is that I'm not arguing for changes to be made to Forth-200x --- I consider Forth-200x to be worthless; also, I am aware that the RfD has been pre-approved by Leon Wagner and is guaranteed to be accepted, so arguing against it is waste of time --- I'm just pointing out that the LFT method can be made to work in a non-standard way in most existing ANS-Forth systems as a stop-gap until Straight Forth is available. > > I understand that. I don't understand why, in that case, you are lurking on the Forth 200x mailing list. It is good for a laugh. This is the thread where HumptyDumpty and I provided the code shown above: https://groups.google.com/forum/#!topic/comp.lang.forth/3LSqmBIZuzY%5B1-25%5D Here I said this: On Tuesday, June 7, 2016 at 7:03:54 PM UTC-7, hughag...@gmail.com wrote: > On Tuesday, June 7, 2016 at 12:37:24 PM UTC-7, Paul Rubin wrote: > > anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > > > Anyway, with the static link and trampolines, we could implement this > > > stuff, but is it worth that cost? > > > > This seems way beyond the simplicity of traditional Forth implementation > > methods and not likely to fly. I'm also not sure whether the quotation > > should be able to modify the parent locals (I guess Pascal allows that) > > or should shadow them like in C++. Overall though, I think people who > > want to program in Lisp probably should do so directly ;-). > ... > I consider this thread to be a joke. Elizabeth Rather has devoted her entire career to preventing general-purpose code from being written in Forth. She is not going to give you guys permission to put anything in Forth-200x that supports general-purpose data-structures. She appoints the committee members, including Anton Ertl, Bernd Paysan and Stephen Pelc and they have to do what she or Leon Wagner tell them to do --- they are tools. I just wrote that VFX code (with REX etc.) as a joke! LOL! Certainly, all of the ANS-Forth cult members absolutely hated my ASSOCIATION.4TH written in ANS-Forth in the novice package, so they are also going to hate the upgraded version written in VFX that uses quotations. When this thread is finished, the ANS-Forth cult members will just continue to use PAD which the ANS-Forth document describes as: "a transient region that can be used to hold data for intermediate processing" --- Elizabeth Rather will continue to post code snippets copied directly out of "Starting Forth" and will continue to claim that all the Forth programmers in the world rely entirely on her to teach them Forth --- Anton Ertl will continue to claim that general-purpose data-structures are the Lisp Way but not the Forth Way (and you will continue to parrot him, as you did above). I just lurk on the Forth-200x mailing-list because that is where the punch-line for my joke will be delivered --- not by me, because I can't post on the Forth-200x mailing-list --- but the punchline gets delivered inadvertently by Forth-200x enthusiasts (only yourself so far). > What you can't expect is for people to change the inner workings of their systems (maybe breaking code of their own) just so they can run your source code, especially if your code has no proven history of use. That is precisely why Standards take so long to evolve. Everybody worries so much about legacy code! --- ANS-Forth killed Forth in 1994, so there is no legacy code --- Forth needs to join the 21st Century, and that is what Straight Forth is all about.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-13 01:25 -0700 |
| Message-ID | <b987113a-208d-47ff-8e3f-0eca6a2f5cdc@googlegroups.com> |
| In reply to | #48981 |
On Saturday, July 9, 2016 at 3:56:08 AM UTC-7, JennyB wrote:
> You have to make the case though, that its worth doing. I haven't seen any application code that needs this, and apparently there is no existing practice of using AQs in any existing Forth system.
>
> Can you point to some application code that would be Standard compliant apart from the fact that it uses this construct, and demonstrate that it is faster, or clearer?
>
> > You are totally not understanding the purpose of allowing the quotation to access the parent function's locals --- the purpose is so the quotation can upfeed data to the parent --- you're assuming that the purpose is to pass data from the parent to the quotation.
>
> OK, show me an example of that.
Okay, here is some simple code borrowed from my Stundurd document and modified slightly to run under ANS-Forth using my REX etc. code.
Here is a HOF that can be used instead of DO loops:
: |iterate { cnt r -- }
begin cnt while
r rex
-1 +to cnt repeat ;
Here are two versions of UP. --- the first uses |ITERATE --- the second uses DO loops.
: up. ( limit n -- ) \ assumes LIMIT is above N
tuck - r[ dup . 1+ ]r |iterate drop ;
: up. \ limit n -- \ assumes LIMIT is above N
?do I . loop ;
Here are two versions of DOWN. --- the first uses |ITERATE --- the second uses DO loops.
: down. ( limit n -- ) \ assumes LIMIT is below N
tuck - negate r[ dup . 1- ]r |iterate drop ;
: down. \ limit n -- \ assumes LIMIT is below N
swap 1+ swap ?do I . -1 +loop ;
The UP. that uses |ITERATE is pretty easy to read, but not necessarily easier to read than the UP. that uses a DO loop. The DOWN. that uses |ITERATE is pretty easy to read and is significantly easier to read than the DOWN. that uses a DO loop --- DO loops are notoriously complicated when going down rather than up.
Here is THROUGH. that uses |ITERATE --- I don't have a version that uses DO loops:
: design ( val -- |val| sign )
dup 0< if negate -1 exit then
1 ;
: through. ( limit n -- )
tuck - \ -- n count
design -rot \ -- step n |count|
r[ dup . over + ]r |iterate 2drop ;
This is a test of this stuff:
10 3 up. 3 4 5 6 7 8 9 ok
3 10 down. 10 9 8 7 6 5 4 ok
10 3 through. 3 4 5 6 7 8 9 ok
3 10 through. 10 9 8 7 6 5 4 ok
Our THROUGH. above is somewhat complicated due to having a lot of stack-juggling. Here is a version that uses locals to improve readability:
: through. { limit n | step -- }
limit n - \ -- count
design to step \ -- |count|
r[ n . step +to n ]r |iterate ;
So, here you have a simple example of a quotation that uses multiple local variables in the parent function, and a HOF that uses local variables of its own.
I will leave it as an exercise for the reader to write THROUGH. using DO loops --- good luck with that!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-13 01:56 -0700 |
| Message-ID | <54585a12-ba48-4da2-a158-ade4be3ebafe@googlegroups.com> |
| In reply to | #49108 |
On Wednesday, July 13, 2016 at 1:25:03 AM UTC-7, hughag...@gmail.com wrote:
> Here is a HOF that can be used instead of DO loops:
>
> : |iterate { cnt r -- }
> begin cnt while
> r rex
> -1 +to cnt repeat ;
Here is a slightly more complicated HOF:
: |until { cnt r | original -- completed }
cnt to original
begin cnt while
r rex
-1 +to cnt
if original cnt - exit then
repeat
original ;
In |ITERATE the quotation didn't return any value, and the HOF didn't return any value either. In |UNTIL the quotation returns a flag that is TRUE if we are done but is FALSE if we are to continue, and the HOF returns a count of how many iterations we completed successfully.
Here is a test of |UNTIL (not intended to be useful; just to show that it works):
: ttt. ( limit n -- )
tuck - r[ dup . 1+ dup 8 = ]r |until nip ;
This is TTT executed with some different parameters for testing:
10 3 ttt. 3 4 5 6 7 ok-1
. 5 ok
7 3 ttt. 3 4 5 6 ok-1
. 4 ok
|UNTIL is also borrowed from my Stundurd document --- I realized when writing this that I had a bug in my Stundurd version of |UNTIL --- what we have here is tested though and does work correctly.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-13 02:09 -0700 |
| Message-ID | <096b2f2b-4851-4877-a793-8e47886f0be7@googlegroups.com> |
| In reply to | #49108 |
On Wednesday, July 13, 2016 at 1:25:03 AM UTC-7, hughag...@gmail.com wrote:
> Here is a HOF that can be used instead of DO loops:
>
> : |iterate { cnt r -- }
> begin cnt while
> r rex
> -1 +to cnt repeat ;
Here is a slightly more complicated HOF:
: |until { cnt r | original -- completed }
cnt to original
begin cnt while
r rex
-1 +to cnt
if original cnt - exit then
repeat
original ;
In |ITERATE the quotation didn't return any value, and the HOF didn't return any value either. In |UNTIL the quotation returns a flag that is TRUE if we are done but is FALSE if we are to continue, and the HOF returns a count of how many iterations we completed successfully.
Here is a test of |UNTIL (not intended to be useful; just to show that it works):
: ttt. ( limit n -- completed )
tuck - r[ dup . 1+ dup 8 = ]r |until nip ;
This is TTT. executed with some different parameters for testing:
10 3 ttt. 3 4 5 6 7 ok-1
. 5 ok
7 3 ttt. 3 4 5 6 ok-1
. 4 ok
This is a version of TTT. that uses a DO loop:
: ttt. ( limit n -- completed )
0 -rot \ -- count limit n
?do
I 8 = if unloop exit then
I . 1+ loop ;
|UNTIL is also borrowed from my Stundurd document --- I realized when writing this that I had a bug in my Stundurd version of |UNTIL --- what we have here is tested though and does work correctly.
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-07-13 14:04 +0000 |
| Message-ID | <nm5hoq$uem$1@dont-email.me> |
| In reply to | #49108 |
hughaguilar96@gmail.com wrote:
> On Saturday, July 9, 2016 at 3:56:08 AM UTC-7, JennyB wrote:
>
> > You have to make the case though, that its worth doing. I
> > haven't seen any application code that needs this, and
> > apparently there is no existing practice of using AQs in any
> > existing Forth system.
> >
> > Can you point to some application code that would be
> > Standard compliant apart from the fact that it uses
> > this construct, and demonstrate that it is faster, or
> > clearer?
> >
> > > You are totally not understanding the purpose of
> > > allowing the quotation to access the parent
> > > function's locals --- the purpose is so the
> > > quotation can upfeed data to the parent --- you're
> > > assuming that the purpose is to pass data from the
> > > parent to the quotation.
> >
> > OK, show me an example of that.
>
> Okay, here is some simple code borrowed
> from my Stundurd document and modified
> slightly to run under ANS-Forth using my
> REX etc. code.
>
> Here is a HOF that can be used instead of DO loops:
>
> : |iterate { cnt r -- }
> begin cnt while
> r rex
> -1 +to cnt repeat ;
Functional languages frown upon mutation. Assuming
that the language that one uses has tail-call
optimization (TCO), he can simple use recursion.
OCaml:
let rec iterate func count =
if count>0 then (func (); iterate func (count-1)) ;;
Better:
let rec iterate func = function
0 -> ()
| n -> func (); iterate func (n-1) ;;
iterate (fun () -> print_char '.') 22 ;;
===>
......................
To show that a huge loop doesn't blow the stack:
iterate
(fun () -> if 0=Random.int 99_000 then print_char '*')
5_000_000 ;;
===>
***************************************
>
> Here are two versions of UP. --- the first
> uses |ITERATE --- the second uses DO loops.
>
> : up. ( limit n -- ) \ assumes LIMIT is above N
> tuck - r[ dup . 1+ ]r |iterate drop ;
>
> : up. \ limit n -- \ assumes LIMIT is above N
> ?do I . loop ;
>
> Here are two versions of DOWN. --- the
> first uses |ITERATE --- the second uses
> DO loops.
>
> : down. ( limit n -- ) \ assumes LIMIT is below N
> tuck - negate r[ dup . 1- ]r |iterate drop ;
>
> : down. \ limit n -- \ assumes LIMIT is below N
> swap 1+ swap ?do I . -1 +loop ;
>
> The UP. that uses |ITERATE is pretty easy to read,
> but not necessarily easier to read than the UP.
> that uses a DO loop. The DOWN. that uses |ITERATE
> is pretty easy to read and is significantly easier
> to read than the DOWN. that uses a DO loop --- DO
> loops are notoriously complicated when going down
> rather than up.
>
> Here is THROUGH. that uses |ITERATE --- I
> don't have a version that uses DO loops:
>
> : design ( val -- |val| sign )
> dup 0< if negate -1 exit then
> 1 ;
>
> : through. ( limit n -- )
> tuck - \ -- n count
> design -rot \ -- step n |count|
> r[ dup . over + ]r |iterate 2drop ;
>
> This is a test of this stuff:
> 10 3 up. 3 4 5 6 7 8 9 ok
> 3 10 down. 10 9 8 7 6 5 4 ok
> 10 3 through. 3 4 5 6 7 8 9 ok
> 3 10 through. 10 9 8 7 6 5 4 ok
>
> Our THROUGH. above is somewhat complicated
> due to having a lot of stack-juggling. Here
> is a version that uses locals to improve
> readability:
>
> : through. { limit n | step -- }
> limit n - \ -- count
> design to step \ -- |count|
> r[ n . step +to n ]r |iterate ;
>
It seems better to make "through" a higher-order function.
(* No mutation; just recursion. *)
let through start limit func =
(* "compare" yields 1, 0, or -1 *)
let step = compare limit start in
let rec loop i =
if i<>limit then (func i; loop (i + step))
in loop start ;;
open Printf ;;
through 3 10 (printf "%d ") ;;
===>
3 4 5 6 7 8 9
through 10 3 (printf "%d ") ;;
===>
10 9 8 7 6 5 4
> So, here you have a simple example of a
> quotation that uses multiple local variables
> in the parent function, and a HOF that uses
> local variables of its own.
>
> I will leave it as an exercise for the
> reader to write THROUGH. using DO loops ---
> good luck with that!
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-14 00:32 -0700 |
| Message-ID | <aec90a33-8203-49d4-808a-eede4c4f2e03@googlegroups.com> |
| In reply to | #49108 |
On Wednesday, July 13, 2016 at 1:25:03 AM UTC-7, hughag...@gmail.com wrote:
> On Saturday, July 9, 2016 at 3:56:08 AM UTC-7, JennyB wrote:
> > You have to make the case though, that its worth doing. I haven't seen any application code that needs this, and apparently there is no existing practice of using AQs in any existing Forth system.
> >
> > Can you point to some application code that would be Standard compliant apart from the fact that it uses this construct, and demonstrate that it is faster, or clearer?
> >
> > > You are totally not understanding the purpose of allowing the quotation to access the parent function's locals --- the purpose is so the quotation can upfeed data to the parent --- you're assuming that the purpose is to pass data from the parent to the quotation.
> >
> > OK, show me an example of that.
> : design ( val -- |val| sign )
> dup 0< if negate -1 exit then
> 1 ;
>
> : through. { limit n | step -- }
> limit n - \ -- count
> design to step \ -- |count|
> r[ n . step +to n ]r |iterate ;
>
> So, here you have a simple example of a quotation that uses multiple local variables in the parent function, and a HOF that uses local variables of its own.
>
> I will leave it as an exercise for the reader to write THROUGH. using DO loops --- good luck with that!
This example still code doesn't answer Jennifer's question. Here the quotation is using locals in the parent function. It is not really upfeeding data to the parent; the parent doesn't do anything with the modified locals after calling the HOF. Also, we are not traversing a data-structure, and I said that supporting general-purpose data-structures is the point. So, all in all, my example code didn't really make my point very well.
The point is to support general-purpose data-structures. The HOF will traverse the data-structure and REX a quotation for every node. The quotation will extract data from all the nodes and put this data in the parent's locals so the parent can use that data. I can't think of any example of this that would be short enough to post on comp.lang.forth. This is really only going to become useful when you have pretty big structs with a lot of fields, and you are doing "queries" on your data-base to extract "meta-data" from your data-base.
I'll describe an example, but for brevity I will not provide all of the code. Lets say that you have a LIST data-structure and you have a HOF called |EACH that traverses it. You have these data-types in your list:
list
w field .name \ ptr to string
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-list >r
hstr r@ .name !
[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 ;
CHICK is a child-class of PERSON. So, every node is of the PERSON class and some are also of the CHICK class. You want to obtain a count of how many people are in your list, how many are chicks, and of the chicks how many are tens, nines and eights (we don't care about them if they are below eight). Here is a function to obtain this valuable information:
: 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 .
;
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-14 01:25 -0700 |
| Message-ID | <f72d7417-b073-4d75-9cd2-ce68d6c993dc@googlegroups.com> |
| In reply to | #49148 |
On Thursday, July 14, 2016 at 2:32:30 AM UTC-5, hughag...@gmail.com wrote:
>
> list
> w field .name \ ptr to string
> w field .gender \ 'M' or 'F' \ if someone isn't one or the other, then he/she isn't a person
> constant person
You're allowing for 2**(8*cell) genders. Mighty progressive of you.
> : 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 .
> ;
This is some kind of hate-coding. Nobody setting out only to write a
serious program would arrive at this. Only by running down a list of
grievances can you remember to use uninitialized locals, etc.
I would end up with something like
: survey ( -- )
#people 0 ?do
i person cabbage? 0= if stats people ++ then
\ XXX: can cabbage be hot?
i person hotness @ dup if
( n ) stats hotties ++
else drop then
loop ;
: .stats ( -- )
cr ." total people: " stats people ?
cr ." total hotties: " stats total-hotties .
cr ." tens: " 10 stats hotties ?
cr ." nines: " 9 stats hotties ?
cr ." eights: " 8 stats hotties ? ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-16 14:52 -0700 |
| Message-ID | <a06d2b8b-5adb-4514-b374-8965af10fb25@googlegroups.com> |
| In reply to | #49153 |
On Thursday, July 14, 2016 at 1:25:15 AM UTC-7, Julian Fondren wrote:
> This is some kind of hate-coding. Nobody setting out only to write a
> serious program would arrive at this. Only by running down a list of
> grievances can you remember to use uninitialized locals, etc.
>
> I would end up with something like
Elizabeth Rather said: I hate locals :-)
Now, we have Julian Fondren the brown-noser writing a program that uses globals rather than locals, and referring to the use of local variables as "hate-coding."
Actually, everybody writing "serious" programs will use local variables rather than global variables. In C a function like this would be written by passing the addresses of the local variables (PEOPLE CHICKS etc.) to the HOF which then passes it to the pseudo-quotation (C doesn't have quotations so it would just use functions similar to what I did in the novice package previously). This is how the pseudo-quotation would upfeed information to the parent function. This is a very cumbersome method --- what I have here in Forth with rquotations is much better than what C has.
ANS-Forth is not capable of doing the C method though, because it is not possible in ANS-Forth to obtain the address of a local variable!!! This is because local variables can only be accessed with TO in ANS-Forth. This is utterly stupid! ANS-Forth has completely screwed up the design of the locals, in every possible way.
I wrote some more HOFs, including |EACH that I used in my hottie-counting example code:
: |each ( i*x head rq -- j*x ) \ quotation: i*x node -- j*x
{ rq | next -- }
begin ?dup while \ -- node
dup .fore @ to next
rq rex
next repeat ;
: |find-node ( i*x head rq -- j*x node|false ) \ quotation: i*x node -- j*x flag
{ node rq | next -- node|false }
begin node while
node .fore @ to next
node rq rex if node exit then
next to node repeat
false ;
: |find-prior ( i*x head rq -- j*x -1|node|false ) \ quotation: i*x node -- j*x flag
-1 { node rq prior | next -- prior|false } \ prior is -1, meaning found node was the head
begin node while
node .fore @ to next
node rq rex if prior exit then
node to prior next to node repeat
false ;
Under VFX these can replace my old EACH FIND-NODE and FIND-PRIOR and they will work fine whether given an rq or xt. In SwiftForth however, these crash when given an xt.
SwiftForth is just a horrible low-quality Forth system! Here is |EACH in SwiftForth:
see |each
48EFBF 8 # EBP SUB 83ED08
48EFC2 EBX 4 [EBP] MOV 895D04
48EFC5 0 # 0 [EBP] MOV C7450000000000
48EFCC 8 # EBX MOV BB08000000
48EFD1 42948F ( LSPACE ) CALL E8B9A4F9FF
48EFD6 9C [ESI] EAX MOV 8B869C000000
48EFDC EBX 0 [EAX] MOV 8918
48EFDE 0 [EBP] EBX MOV 8B5D00
48EFE1 4 # EBP ADD 83C504
48EFE4 9C [ESI] EAX MOV 8B869C000000
48EFEA EBX 4 [EAX] MOV 895804
48EFED 0 [EBP] EBX MOV 8B5D00
48EFF0 4 # EBP ADD 83C504
48EFF3 EBX EBX OR 09DB
48EFF5 48F002 JNZ 750B
48EFF7 0 [EBP] EBX MOV 8B5D00
48EFFA 4 # EBP ADD 83C504
48EFFD 48F03F JMP E93D000000
48F002 4 # EBP SUB 83ED04
48F005 EBX 0 [EBP] MOV 895D00
48F008 0 [EBX] EBX MOV 8B1B
48F00A 9C [ESI] EAX MOV 8B869C000000
48F010 EBX 0 [EAX] MOV 8918
48F012 0 [EBP] EBX MOV 8B5D00
48F015 4 # EBP ADD 83C504
48F018 4 # EBP SUB 83ED04
48F01B EBX 0 [EBP] MOV 895D00
48F01E 9C [ESI] EBX MOV 8B9E9C000000
48F024 4 [EBX] EBX MOV 8B5B04
48F027 48E9DF ( rex ) CALL E8B3F9FFFF
48F02C 4 # EBP SUB 83ED04
48F02F EBX 0 [EBP] MOV 895D00
48F032 9C [ESI] EBX MOV 8B9E9C000000
48F038 0 [EBX] EBX MOV 8B1B
48F03A 48EFF3 JMP E9B4FFFFFF
48F03F RET C3 ok
This is truly crappy code! There is almost no optimization being done. We don't even have peephole-optimization (notice how at 48F015 we add 4 to EBP and then subtract 4 from EBP). Also, the local-frame pointer is not a register, but it is a user-variable in memory, which makes every local reference slow and bloaty.
Forth Inc. is holding back progress! The Forth-200x committee is refusing to support quotations because SwiftForth has bugs that prevent my REX from calling an xt as well as an rq, so they want to ban REX from being used. Also, SwiftForth produces grossly inefficient code when functions use local variables, so the Forth-200x committee is striving to prevent Forth programmers from using local variables --- they are purposely screwing up the design of locals to make them unusable.
The only way for Forth to succeed is if a new Standard is developed --- Forth Inc. will not be allowed to screw this one up! --- the Standard has to be designed by programmers, not by an idiot sales-person.
The problem with VFX is primarily that it is for the 32-bit x86 which has been obsolete for many years (I don't think they are even sold now). I would expect Straight Forth to be significantly faster than VFX just because Straight Forth is for the 64-bit x86 that has 16 registers whereas VFX is for the 32-bit x86 that has only 8 registers. VFX does generate good code for the 32-bit x86 however --- here is |EACH in VFX:
see |each
|EACH
( 004E0200 8BD4 ) MOV EDX, ESP
( 004E0202 53 ) PUSH EBX
( 004E0203 6A00 ) PUSH 00
( 004E0205 52 ) PUSH EDX
( 004E0206 57 ) PUSH EDI
( 004E0207 8BFC ) MOV EDI, ESP
( 004E0209 81EC00000000 ) SUB ESP, 00000000
( 004E020F 8B5D00 ) MOV EBX, [EBP]
( 004E0212 8D6D04 ) LEA EBP, [EBP+04]
( 004E0215 90 ) NOP
( 004E0216 90 ) NOP
( 004E0217 90 ) NOP
( 004E0218 85DB ) TEST EBX, EBX
( 004E021A 750B ) JNZ/NE 004E0227
( 004E021C 8B5D00 ) MOV EBX, [EBP]
( 004E021F 8D6D04 ) LEA EBP, [EBP+04]
( 004E0222 E91E000000 ) JMP 004E0245
( 004E0227 8B13 ) MOV EDX, 0 [EBX]
( 004E0229 895708 ) MOV [EDI+08], EDX
( 004E022C 8D6DFC ) LEA EBP, [EBP+-04]
( 004E022F 895D00 ) MOV [EBP], EBX
( 004E0232 8B5F0C ) MOV EBX, [EDI+0C]
( 004E0235 E846F7FFFF ) CALL 004DF980 REX
( 004E023A 8D6DFC ) LEA EBP, [EBP+-04]
( 004E023D 895D00 ) MOV [EBP], EBX
( 004E0240 8B5F08 ) MOV EBX, [EDI+08]
( 004E0243 EBD3 ) JMP 004E0218
( 004E0245 8B6704 ) MOV ESP, [EDI+04]
( 004E0248 8B3F ) MOV EDI, 0 [EDI]
( 004E024A C3 ) NEXT,
( 75 bytes, 30 instructions )
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-16 20:25 -0700 |
| Message-ID | <05992aca-7579-4935-bd11-dca3b71cc7b9@googlegroups.com> |
| In reply to | #49197 |
On Saturday, July 16, 2016 at 2:52:26 PM UTC-7, hughag...@gmail.com wrote:
> I wrote some more HOFs, including |EACH that I used in my hottie-counting example code:
>
> : |each ( i*x head rq -- j*x ) \ quotation: i*x node -- j*x
> { rq | next -- }
> begin ?dup while \ -- node
> dup .fore @ to next
> rq rex
> next repeat ;
> ...
> VFX does generate good code for the 32-bit x86 however --- here is |EACH in VFX:
>
> see |each
> |EACH
> ( 004E0200 8BD4 ) MOV EDX, ESP
> ( 004E0202 53 ) PUSH EBX
> ( 004E0203 6A00 ) PUSH 00
> ( 004E0205 52 ) PUSH EDX
> ( 004E0206 57 ) PUSH EDI
> ( 004E0207 8BFC ) MOV EDI, ESP
> ( 004E0209 81EC00000000 ) SUB ESP, 00000000
> ( 004E020F 8B5D00 ) MOV EBX, [EBP]
> ( 004E0212 8D6D04 ) LEA EBP, [EBP+04]
> ( 004E0215 90 ) NOP
> ( 004E0216 90 ) NOP
> ( 004E0217 90 ) NOP
> ( 004E0218 85DB ) TEST EBX, EBX
> ( 004E021A 750B ) JNZ/NE 004E0227
> ( 004E021C 8B5D00 ) MOV EBX, [EBP]
> ( 004E021F 8D6D04 ) LEA EBP, [EBP+04]
> ( 004E0222 E91E000000 ) JMP 004E0245
> ( 004E0227 8B13 ) MOV EDX, 0 [EBX]
> ( 004E0229 895708 ) MOV [EDI+08], EDX
> ( 004E022C 8D6DFC ) LEA EBP, [EBP+-04]
> ( 004E022F 895D00 ) MOV [EBP], EBX
> ( 004E0232 8B5F0C ) MOV EBX, [EDI+0C]
> ( 004E0235 E846F7FFFF ) CALL 004DF980 REX
> ( 004E023A 8D6DFC ) LEA EBP, [EBP+-04]
> ( 004E023D 895D00 ) MOV [EBP], EBX
> ( 004E0240 8B5F08 ) MOV EBX, [EDI+08]
> ( 004E0243 EBD3 ) JMP 004E0218
> ( 004E0245 8B6704 ) MOV ESP, [EDI+04]
> ( 004E0248 8B3F ) MOV EDI, 0 [EDI]
> ( 004E024A C3 ) NEXT,
> ( 75 bytes, 30 instructions )
This is the EACH code:
: each ( i*x head 'toucher -- j*x ) \ toucher: i*x node -- j*x
>r
begin dup while \ -- node \r: -- 'toucher
r@ over .fore @ >r \ -- node 'toucher \r: -- 'toucher next
execute r> repeat drop
rdrop ;
This is EACH in VFX:
see each
EACH
( 004E00A0 53 ) PUSH EBX
( 004E00A1 8B5D00 ) MOV EBX, [EBP]
( 004E00A4 8D6D04 ) LEA EBP, [EBP+04]
( 004E00A7 90 ) NOP
( 004E00A8 85DB ) TEST EBX, EBX
( 004E00AA 0F8415000000 ) JZ/E 004E00C5
( 004E00B0 8B1424 ) MOV EDX, [ESP]
( 004E00B3 8B0B ) MOV ECX, 0 [EBX]
( 004E00B5 51 ) PUSH ECX
( 004E00B6 8BCA ) MOV ECX, EDX
( 004E00B8 FFD1 ) CALL ECX
( 004E00BA 5A ) POP EDX
( 004E00BB 8D6DFC ) LEA EBP, [EBP+-04]
( 004E00BE 895D00 ) MOV [EBP], EBX
( 004E00C1 8BDA ) MOV EBX, EDX
( 004E00C3 EBE3 ) JMP 004E00A8
( 004E00C5 8D642404 ) LEA ESP, [ESP+04]
( 004E00C9 8B5D00 ) MOV EBX, [EBP]
( 004E00CC 8D6D04 ) LEA EBP, [EBP+04]
( 004E00CF C3 ) NEXT,
( 48 bytes, 20 instructions )
In VFX |EACH and EACH are interchangeable --- |EACH can use an xt although it is designed to use an rq --- EACH can use an rq although it is designed to use an xt.
|EACH is more robust than EACH because it allows an rquotation to upfeed information to the parent function through its local variables, so an easy solution is to just use |EACH all the time and forget about EACH altogether. EACH is faster than |EACH however, so a better solution is to only use |EACH when the quotation is actually upfeeding data to the parent function, but use EACH otherwise.
Speed is important when working with large amounts of data. In my slide-rule program I had lists with 1500 elements. The code generated by SwiftForth was so grossly inefficient that the program noticeably dragged. I wrote a lot of low-level code, including EACH, in assembly-language and doubled the speed. The HOF is typically iterating through a data-structure and executing the quotation for every element, so if the data-structure is large then the HOF speed can be a major factor in the program's overall speed.
One reason why it is a good idea to have general-purpose code is that it can be written in assembly-language for speed. I could write EACH in assembly-language to significantly boost the speed of my SwiftForth program. If I had followed Elizabeth Rather's advice and cut-and-paste the list-traversal code into my program everywhere that it was needed, I wouldn't have been able to make that code assembly-language but would have kept it as Forth to make the cut-and-paste easier. Elizabeth Rather claims that doing cut-and-paste results in super-optimized programs that do "exactly what you want" so that you are in "total control" --- cut-and-paste actually results in inefficient and bloated programs --- cut-and-paste is what script kiddies do so they can pack their program with code written by somebody else (a real programmer) and pretend that they wrote it themselves.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web