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-12 11:05 -0700 |
| Articles | 20 on this page of 151 — 25 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 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 hughaguilar96@gmail.com - 2016-08-12 11:05 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-17 23:49 -0700 |
| Subject | Re: Universal Delimiters - was Re: 3rd RfD: Quotations |
| Message-ID | <209f4f82-29ec-4040-92d3-e00af8cb7455@googlegroups.com> |
| In reply to | #49206 |
On Sunday, July 17, 2016 at 8:32:16 AM UTC-7, humptydumpty wrote: > To give a proper formal way for '*CASE' and '*OF', > I should define: > > : *CASE ends> ; IMMEDIATE > > : *OF POSTPONE OVER POSTPONE = > POSTPONE IF > POSTPONE DROP > ends> \ get action ended by 'END' > POSTPONE ELSE > ends> \ alternative: go for next > POSTPONE THEN > POSTPONE end > ; IMMEDIATE HumptyDumpty --- your code implementing quotations was pretty good --- this code for CASE is terrible though. Every language in the world compiles CASE (or SWITCH in C) as a jump-table. Even HLA does this, and HLA is an assembly-language. Only ANS-Forth compiles CASE as a series of IF statements. This yet another example of Elizabeth Rather's incompetence. There was a contest in "Forth Dimensions" way back in the 1980s for a CASE statement, and this code with the series of IF statements won the contest, then Elizabeth Rather put it in ANS-Forth because it was supposedly the state-of-the-art. She was not considering the fact that the contest required the CASE to be written in Forth as an extension on top of Forth. This is most likely why this technique was used, with the series of IF statements --- it was trivial to write. She was also not considering the fact that nobody took the contest very seriously (there was no prize money), so nobody was going to bother with anything that took more than one hour to write. I doubt that there were any entries to the contest other than this one with the series of IF statements. Anyway, like most of ANS-Forth, the CASE statement is crap. This is grossly inefficient! This is worthless! This kind of code is the hallmark of Elizabeth Rather --- total crap --- she can't write Forth code herself, so she just borrows Forth code from wherever she can find it (in this case from the pages of "Forth Dimensions"). It is possible to write a Forth interpreter in C using a gigantic SWITCH statement for all of the primitives. It is not very fast compared to a Forth system written in assembly-language, but it is okay for toy programs. It is not possible to write an interpreter for any language in ANS-Forth using a gigantic CASE statement for all the primitives, because the ANS-Forth does a sequential search in CASE which is orders of magnitude slower than necessary. Many many C programmers have written a Forth interpreter in C just so they could say that C is the "god language" and that Forth is a toy language --- they always claim to be big experts on Forth because they have written a Forth interpreter --- in the next breath they claim that Forth is utterly worthless --- writing a Forth interpreter is interesting as a learning-experience for C novices, but the Forth interpreter itself is just a silly toy (this is how Anton Ertl sells his gForth class to his students). Anyway, my point is that you are allowing Elizabeth Rather to dictate limitations which are not necessary --- no other language has these limitations --- every other language compiles a jump-table.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-07-18 00:39 -0700 |
| Subject | Re: Universal Delimiters - was Re: 3rd RfD: Quotations |
| Message-ID | <12fa5e9f-7843-4d5e-996d-66fea889b6a1@googlegroups.com> |
| In reply to | #49214 |
On Monday, July 18, 2016 at 9:49:15 AM UTC+3, hughag...@gmail.com wrote: > On Sunday, July 17, 2016 at 8:32:16 AM UTC-7, humptydumpty wrote: > > To give a proper formal way for '*CASE' and '*OF', > > I should define: > > > > : *CASE ends> ; IMMEDIATE > > > > : *OF POSTPONE OVER POSTPONE = > > POSTPONE IF > > POSTPONE DROP > > ends> \ get action ended by 'END' > > POSTPONE ELSE > > ends> \ alternative: go for next > > POSTPONE THEN > > POSTPONE end > > ; IMMEDIATE > > HumptyDumpty --- your code implementing quotations was pretty good --- this code for CASE is terrible though. > > Every language in the world compiles CASE (or SWITCH in C) as a jump-table. Even HLA does this, and HLA is an assembly-language. Only ANS-Forth compiles CASE as a series of IF statements. This yet another example of Elizabeth Rather's incompetence. There was a contest in "Forth Dimensions" way back in the 1980s for a CASE statement, and this code with the series of IF statements won the contest, then Elizabeth Rather put it in ANS-Forth because it was supposedly the state-of-the-art. She was not considering the fact that the contest required the CASE to be written in Forth as an extension on top of Forth. This is most likely why this technique was used, with the series of IF statements --- it was trivial to write. She was also not considering the fact that nobody took the contest very seriously (there was no prize money), so nobody was going to bother with anything that took more than one hour to write. I doubt that there were any entries to the contest other than this one with the series of IF statements. > > Anyway, like most of ANS-Forth, the CASE statement is crap. This is grossly inefficient! This is worthless! This kind of code is the hallmark of Elizabeth Rather --- total crap --- she can't write Forth code herself, so she just borrows Forth code from wherever she can find it (in this case from the pages of "Forth Dimensions"). > > It is possible to write a Forth interpreter in C using a gigantic SWITCH statement for all of the primitives. It is not very fast compared to a Forth system written in assembly-language, but it is okay for toy programs. It is not possible to write an interpreter for any language in ANS-Forth using a gigantic CASE statement for all the primitives, because the ANS-Forth does a sequential search in CASE which is orders of magnitude slower than necessary. Many many C programmers have written a Forth interpreter in C just so they could say that C is the "god language" and that Forth is a toy language --- they always claim to be big experts on Forth because they have written a Forth interpreter --- in the next breath they claim that Forth is utterly worthless --- writing a Forth interpreter is interesting as a learning-experience for C novices, but the Forth interpreter itself is just a silly toy (this is how Anton Ertl sells his gForth class to his students). > > Anyway, my point is that you are allowing Elizabeth Rather to dictate limitations which are not necessary --- no other language has these limitations --- every other language compiles a jump-table. Hi! Is just an exercise in new developed macro technique, that applies a macro to macro to another macro. That macro technique you'll find it in 'nmacro.fs' section. Just 6 lines of code: 4 for a quick&dirty small-stack and 2 lines to implement 'END' 'ENDS>' words. That two words manipulates the flow of compiling (through manipulation of return stack continuations) in such a way that it compiles directly a sequence of words from outside of body macro, not using text(expanded or not)+'evaluate' nor compiling an 'XT' into. A sketch of use: : HOF postpone A ENDS> postpone C ; immediate inside of a definition have to write " HOF X Y Z END " , now forth compiler compiles sequence 'A X Y Z C' directly into that definition. That is all about, a macro technique. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-07-16 07:57 -0700 |
| Subject | Re: Universal Delimiters - was Re: 3rd RfD: Quotations |
| Message-ID | <e757b220-a088-423e-9fa5-12a9585af741@googlegroups.com> |
| In reply to | #49188 |
On Saturday, July 16, 2016 at 4:41:54 PM UTC+3, Coos Haak wrote: > Op Sat, 16 Jul 2016 05:47:49 -0700 (PDT) schreef humptydumpty: > > > On Saturday, July 16, 2016 at 12:42:58 PM UTC+3, JennyB wrote: > >> On Saturday, 16 July 2016 07:30:48 UTC+1, humptydumpty wrote: > >> > >>> > >>> I think that XT is more appropriate to *a* forth word, > >>> but for *sequences of words* more flexible approach would be a continuation, > >>> ex: > >>> > >>> : rex >R ; ok > >>> :noname 0 . 1 . 2 . ; cr execute > >>> 0 1 2 ok > >>> : R R> ; ok > >>> :noname R 0 . 1 . 2 . ; execute cr rex > >>> 0 1 2 ok > >>> .s <0> ok > >>> :noname 0 . R 1 . 2 . ; execute cr rex .s 0 > >>> 1 2 <0> ok > >>> :noname 0 . 1 . R 2 . ; execute cr rex .s 0 1 > >>> 2 <0> ok > >>> > >> This reminded me of something: Gordon Charlton's Universal Delimiter in Forthwrite FigUK April 1990 > >> > >> ENDS> and END have the same functionality as R and REX respectively, except that END is immediate and has a little compiler security - it aborts if given anything not pushed by ENDS> > >> > >> Gordon gives as examples a control word set, which could nowadays be defined as: > >> > >>: *IF POSTPONE IF ENDS> POSTPONE THEN ; IMMEDIATE > >>: *BEGIN POSTPONE BEGIN ENDS> POSTPONE AGAIN ; IMMEDIATE > >>: *UNTIL POSTPONE BEGIN ENDS> POSTPONE UNTIL ; IMMEDIATE > >>: *WHILE \ allows multiple branches to a single END > >> POSTPONE WHILE ENDS> POSTPONE END \ resolve outer structure > >> POSTPONE THEN ; IMMEDIATE \ and then this branch > >>: *CASE ENDS> POSTPONE DROP ; IMMEDIATE > >>: *OF POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP > >> ENDS> POSTPONE ELSE \ action of ENDOF > >> ENDS> POSTPONE END POSTPONE THEN ; IMMEDIATE > >> > >> syntax *if ... end > >> *if... else ... end > >> > >> begin ... end > >> until ... end > >> case ... end > >> > >> each of which may be exited by multiple instances of while or of ... end > >> > >> End alway completes the most recent unfinished continuation. > >> > >> This suggests a syntax for HOFs: > >> > >> ] HOF code it calls END [ > >> > >> but that is only possible within a definition. > > > > Hi! > > > > Thanks! Cool hack for compile-time! Here a quick&dirty guess: > > > > VARIABLE Cont ok > >: ends> R> Cont ! ; ok > >: end Cont @ >R ; immediate ok > >: *IF postpone IF ends> postpone THEN ; immediate ok > > ok > >: test *IF -1 . ELSE 0 . end ; ok > > see test > >: test > > IF -1 . > > ELSE 0 . > > THEN ; ok > > > > Have a nice day, > > humptydumpty > > This is not nestable, use another stack, perhaps the locals one. > > : ends> r> >l ; > : end l> >r ; immediate > > groet Coos Hi! Yes! I think that 'ends>' 'end' pair could be used as a base for a valuable macro technique. :) Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2016-07-18 12:18 +0200 |
| Subject | Re: Universal Delimiters - was Re: 3rd RfD: Quotations |
| Message-ID | <x52tiaysf888$.l2bysfp2mqx.dlg@40tude.net> |
| In reply to | #49191 |
Op Sat, 16 Jul 2016 07:57:28 -0700 (PDT) schreef humptydumpty:
> On Saturday, July 16, 2016 at 4:41:54 PM UTC+3, Coos Haak wrote:
>> Op Sat, 16 Jul 2016 05:47:49 -0700 (PDT) schreef humptydumpty:
>>
>>> On Saturday, July 16, 2016 at 12:42:58 PM UTC+3, JennyB wrote:
>>>> On Saturday, 16 July 2016 07:30:48 UTC+1, humptydumpty wrote:
>>>>
>>>>>
>>>>> I think that XT is more appropriate to *a* forth word,
>>>>> but for *sequences of words* more flexible approach would be a continuation,
>>>>> ex:
>>>>>
>>>>> : rex >R ; ok
>>>>> :noname 0 . 1 . 2 . ; cr execute
>>>>> 0 1 2 ok
>>>>> : R R> ; ok
>>>>> :noname R 0 . 1 . 2 . ; execute cr rex
>>>>> 0 1 2 ok
>>>>> .s <0> ok
>>>>> :noname 0 . R 1 . 2 . ; execute cr rex .s 0
>>>>> 1 2 <0> ok
>>>>> :noname 0 . 1 . R 2 . ; execute cr rex .s 0 1
>>>>> 2 <0> ok
>>>>>
>>>> This reminded me of something: Gordon Charlton's Universal Delimiter in Forthwrite FigUK April 1990
>>>>
>>>> ENDS> and END have the same functionality as R and REX respectively, except that END is immediate and has a little compiler security - it aborts if given anything not pushed by ENDS>
>>>>
>>>> Gordon gives as examples a control word set, which could nowadays be defined as:
>>>>
>>>>: *IF POSTPONE IF ENDS> POSTPONE THEN ; IMMEDIATE
>>>>: *BEGIN POSTPONE BEGIN ENDS> POSTPONE AGAIN ; IMMEDIATE
>>>>: *UNTIL POSTPONE BEGIN ENDS> POSTPONE UNTIL ; IMMEDIATE
>>>>: *WHILE \ allows multiple branches to a single END
>>>> POSTPONE WHILE ENDS> POSTPONE END \ resolve outer structure
>>>> POSTPONE THEN ; IMMEDIATE \ and then this branch
>>>>: *CASE ENDS> POSTPONE DROP ; IMMEDIATE
>>>>: *OF POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP
>>>> ENDS> POSTPONE ELSE \ action of ENDOF
>>>> ENDS> POSTPONE END POSTPONE THEN ; IMMEDIATE
>>>>
>>>> syntax *if ... end
>>>> *if... else ... end
>>>>
>>>> begin ... end
>>>> until ... end
>>>> case ... end
>>>>
>>>> each of which may be exited by multiple instances of while or of ... end
>>>>
>>>> End alway completes the most recent unfinished continuation.
>>>>
>>>> This suggests a syntax for HOFs:
>>>>
>>>> ] HOF code it calls END [
>>>>
>>>> but that is only possible within a definition.
>>>
>>> Hi!
>>>
>>> Thanks! Cool hack for compile-time! Here a quick&dirty guess:
>>>
>>> VARIABLE Cont ok
>>>: ends> R> Cont ! ; ok
>>>: end Cont @ >R ; immediate ok
>>>: *IF postpone IF ends> postpone THEN ; immediate ok
>>> ok
>>>: test *IF -1 . ELSE 0 . end ; ok
>>> see test
>>>: test
>>> IF -1 .
>>> ELSE 0 .
>>> THEN ; ok
>>>
>>> Have a nice day,
>>> humptydumpty
>>
>> This is not nestable, use another stack, perhaps the locals one.
>>
>>: ends> r> >l ;
>>: end l> >r ; immediate
>>
>> groet Coos
>
> Hi!
>
> Yes!
> I think that 'ends>' 'end' pair could be used as a base
> for a valuable macro technique. :)
>
> Have a nice day,
> humptydumpty
And more, nesting remains possibler with the locals stack ignored:
: ends> r> ;
: end >r ; immediate
quotations:
: [:
postpone ahead here -rot
ends> postpone exit postpone then postpone literal
; immediate
: ;] >r ; immediate \ or an alias of end
: greet [: ." world" ;]
." hello" execute ;
In some (e.g. mine) implementations, use : >EXEC >R ; instead of EXECUTE.
groet Coos
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-07-18 04:04 -0700 |
| Subject | Re: Universal Delimiters - was Re: 3rd RfD: Quotations |
| Message-ID | <ea3156fa-a117-425c-9a1c-83a5cd3cec6b@googlegroups.com> |
| In reply to | #49216 |
On Monday, July 18, 2016 at 1:18:57 PM UTC+3, Coos Haak wrote: > Op Sat, 16 Jul 2016 07:57:28 -0700 (PDT) schreef humptydumpty: > > > On Saturday, July 16, 2016 at 4:41:54 PM UTC+3, Coos Haak wrote: > >> Op Sat, 16 Jul 2016 05:47:49 -0700 (PDT) schreef humptydumpty: > >> > >>> On Saturday, July 16, 2016 at 12:42:58 PM UTC+3, JennyB wrote: > >>>> On Saturday, 16 July 2016 07:30:48 UTC+1, humptydumpty wrote: > >>>> > >>>>> > >>>>> I think that XT is more appropriate to *a* forth word, > >>>>> but for *sequences of words* more flexible approach would be a continuation, > >>>>> ex: > >>>>> > >>>>> : rex >R ; ok > >>>>> :noname 0 . 1 . 2 . ; cr execute > >>>>> 0 1 2 ok > >>>>> : R R> ; ok > >>>>> :noname R 0 . 1 . 2 . ; execute cr rex > >>>>> 0 1 2 ok > >>>>> .s <0> ok > >>>>> :noname 0 . R 1 . 2 . ; execute cr rex .s 0 > >>>>> 1 2 <0> ok > >>>>> :noname 0 . 1 . R 2 . ; execute cr rex .s 0 1 > >>>>> 2 <0> ok > >>>>> > >>>> This reminded me of something: Gordon Charlton's Universal Delimiter in Forthwrite FigUK April 1990 > >>>> > >>>> ENDS> and END have the same functionality as R and REX respectively, except that END is immediate and has a little compiler security - it aborts if given anything not pushed by ENDS> > >>>> > >>>> Gordon gives as examples a control word set, which could nowadays be defined as: > >>>> > >>>>: *IF POSTPONE IF ENDS> POSTPONE THEN ; IMMEDIATE > >>>>: *BEGIN POSTPONE BEGIN ENDS> POSTPONE AGAIN ; IMMEDIATE > >>>>: *UNTIL POSTPONE BEGIN ENDS> POSTPONE UNTIL ; IMMEDIATE > >>>>: *WHILE \ allows multiple branches to a single END > >>>> POSTPONE WHILE ENDS> POSTPONE END \ resolve outer structure > >>>> POSTPONE THEN ; IMMEDIATE \ and then this branch > >>>>: *CASE ENDS> POSTPONE DROP ; IMMEDIATE > >>>>: *OF POSTPONE OVER POSTPONE = POSTPONE IF POSTPONE DROP > >>>> ENDS> POSTPONE ELSE \ action of ENDOF > >>>> ENDS> POSTPONE END POSTPONE THEN ; IMMEDIATE > >>>> > >>>> syntax *if ... end > >>>> *if... else ... end > >>>> > >>>> begin ... end > >>>> until ... end > >>>> case ... end > >>>> > >>>> each of which may be exited by multiple instances of while or of ... end > >>>> > >>>> End alway completes the most recent unfinished continuation. > >>>> > >>>> This suggests a syntax for HOFs: > >>>> > >>>> ] HOF code it calls END [ > >>>> > >>>> but that is only possible within a definition. > >>> > >>> Hi! > >>> > >>> Thanks! Cool hack for compile-time! Here a quick&dirty guess: > >>> > >>> VARIABLE Cont ok > >>>: ends> R> Cont ! ; ok > >>>: end Cont @ >R ; immediate ok > >>>: *IF postpone IF ends> postpone THEN ; immediate ok > >>> ok > >>>: test *IF -1 . ELSE 0 . end ; ok > >>> see test > >>>: test > >>> IF -1 . > >>> ELSE 0 . > >>> THEN ; ok > >>> > >>> Have a nice day, > >>> humptydumpty > >> > >> This is not nestable, use another stack, perhaps the locals one. > >> > >>: ends> r> >l ; > >>: end l> >r ; immediate > >> > >> groet Coos > > > > Hi! > > > > Yes! > > I think that 'ends>' 'end' pair could be used as a base > > for a valuable macro technique. :) > > > > Have a nice day, > > humptydumpty Hi! > > And more, nesting remains possibler with the locals stack ignored: > > : ends> r> ; > : end >r ; immediate > It looks that will suffice, if is no unbalanced structure! :)) > quotations: > > : [: > postpone ahead here -rot > ends> postpone exit postpone then postpone literal > ; immediate > > : ;] >r ; immediate \ or an alias of end > > : greet [: ." world" ;] > ." hello" execute ; > > In some (e.g. mine) implementations, use : >EXEC >R ; instead of EXECUTE. > Cool! Yet looks implementations dependent (a little :) . If have enough memory we could use directly 'ends>' 'end' macro technique :) > groet Coos Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-10 21:23 -0700 |
| Message-ID | <5a7e3f2e-8ca5-4a2f-8b9b-85851830248c@googlegroups.com> |
| In reply to | #48974 |
On Friday, July 8, 2016 at 10:28:27 PM UTC-7, hughag...@gmail.com wrote:
> 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.
Okay, I looked at SwiftForth some more and ESI is the user-variable pointer not the local-frame pointer --- the local-frame pointer is a user-variable.
As usual, SwiftForth code is grossly over-complicated. I figured it out though. Just as a joke, here is code for both VFX (slightly upgraded to be more efficient) and SwiftForth (not totally trivial, but reasonably easy to write):
\ in the stack-picture comments, R is a continuation (a vector to a quotation)
VFX? SwiftForth? or [if]
\ My code ( VFX or SwiftForth only) requires that the HOF does have local variables.
: 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
VFX? [if]
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
mov eax, ebx
mov ebx, 0 [ebp] lea ebp, w [ebp]
call eax
pop edi \ restore HOF's LF
next, end-code
[then]
SwiftForth? [if]
156 constant lf-offset \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)
code rex ( r -- ) \ HumptyDumpty called this RCALL
lf-offset [esi] edx mov
edx push \ this is the HOF's LF which won't be used by the quotation
-4 [edx] eax mov \ this is the old ESP
0 [eax] eax mov \ this is the parent's LF which will be used by the quotation
eax lf-offset [esi] mov
ebx eax mov [drop]
eax call
lf-offset [esi] pop \ restore HOF's LF
ret end-code
[then]
[else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX
: 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
\ HumptyDumpty's code requires that the HOF does not have local variables.
[then]
\ char & comment \ this only works for my code (VFX or SwiftForth)
: test-hof { r | y -- }
9 to y
cr ." enter TEST-HOF " y . \ should be 9
3 0 do r rex loop
cr ." leave TEST-HOF " y . \ should be 9
;
: test { | x -- }
10 to x
cr ." before: " x . \ should be 10
r[ 1 +to x ]r test-hof
cr ." after: " x . \ should be 13
;
&
[toc] | [prev] | [next] | [standalone]
| From | Lars Brinkhoff <lars.spam@nocrew.org> |
|---|---|
| Date | 2016-07-09 14:30 +0200 |
| Message-ID | <861t33ouxl.fsf@molnjunk.nocrew.org> |
| In reply to | #48969 |
JennyB <jennybrien@googlemail.com> writes: > there is normally is no sense in trying to access parent locals in > that situation, when the parent is no longer in scope. I disagree. This is routinely done in many other languages. They're usually called "closures". Whether it would be appropriate in Forth is another matter, because it's a tradeoff between simplicity and expressiveness.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2016-07-09 05:51 -0700 |
| Message-ID | <f4a21c05-5d24-4985-bfd6-57bbf4b466b9@googlegroups.com> |
| In reply to | #48982 |
On Saturday, July 9, 2016 at 2:30:33 PM UTC+2, Lars Brinkhoff wrote: > JennyB <jennybrien@googlemail.com> writes: > > there is normally is no sense in trying to access parent locals in > > that situation, when the parent is no longer in scope. > > I disagree. This is routinely done in many other languages. They're > usually called "closures". Whether it would be appropriate in Forth is > another matter, because it's a tradeoff between simplicity and > expressiveness. So what happens when I use this concept in a recursive word that calls other [ (mutually) recursive ] words? One of the called words could be EVALUATE . Is the full Forth system pushed on a big stack (in the cloud) somewhere, for each execution of the recursion? What happens when a closure receives a pointer to something and stores it in its locals. Can it depend on the object *pointed to* being valid forever? -marcel
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-09 09:01 -0500 |
| Message-ID | <JOOdnYUu6M8CnhzKnZ2dnUU7-UmdnZ2d@supernews.com> |
| In reply to | #48983 |
mhx@iae.nl wrote: > On Saturday, July 9, 2016 at 2:30:33 PM UTC+2, Lars Brinkhoff wrote: >> JennyB <jennybrien@googlemail.com> writes: >> > there is normally is no sense in trying to access parent locals in >> > that situation, when the parent is no longer in scope. >> >> I disagree. This is routinely done in many other languages. >> They're usually called "closures". Whether it would be appropriate >> in Forth is another matter, because it's a tradeoff between >> simplicity and expressiveness. > > So what happens when I use this concept in a recursive word that > calls other [ (mutually) recursive ] words? One of the called > words could be EVALUATE . Is the full Forth system pushed > on a big stack (in the cloud) somewhere, for each execution > of the recursion? Closures only capture the values that they name. They don't need to capture the entire Forth system. > What happens when a closure receives a pointer to something and > stores it in its locals. Can it depend on the object *pointed > to* being valid forever? This is Forth. All of the usual rules still apply. If the object pointed to is still accessible (i.e. it is in data space) then it's valid. Why do you ask? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2016-07-09 07:40 -0700 |
| Message-ID | <ae64228a-b5b9-4e9e-ae07-963458edb6e9@googlegroups.com> |
| In reply to | #48984 |
On Saturday, 9 July 2016 15:01:08 UTC+1, Andrew Haley wrote: > mhx@iae.nl wrote: > > On Saturday, July 9, 2016 at 2:30:33 PM UTC+2, Lars Brinkhoff wrote: > >> JennyB <jennybrien@googlemail.com> writes: > >> > there is normally is no sense in trying to access parent locals in > >> > that situation, when the parent is no longer in scope. > >> > >> I disagree. This is routinely done in many other languages. > >> They're usually called "closures". Whether it would be appropriate > >> in Forth is another matter, because it's a tradeoff between > >> simplicity and expressiveness. > > > > So what happens when I use this concept in a recursive word that > > calls other [ (mutually) recursive ] words? One of the called > > words could be EVALUATE . Is the full Forth system pushed > > on a big stack (in the cloud) somewhere, for each execution > > of the recursion? > > Closures only capture the values that they name. They don't need to > capture the entire Forth system. > > > What happens when a closure receives a pointer to something and > > stores it in its locals. Can it depend on the object *pointed > > to* being valid forever? > > This is Forth. All of the usual rules still apply. If the object > pointed to is still accessible (i.e. it is in data space) then it's > valid. Why do you ask? > > Andrew. That's why I said it would normally make no sense to execute a quotation that references its parent's locals when the parent is no longer in scope. The local reference doesn't capture a value, it compiles a bit of code that says "fetch me what is at this offset from the address that on the local stack when I run" or something similar. So when it runs you've got to make sure the local stack points to a relevant address. Hugh's code manages that for a particular set of circumstances: when the quotation had no locals of its own and is consumed within the parent word by a HOF that does have locals and there are no other nested definitions between the quotation and the parent. Outside its parent, the quotation could only be meaningfully be executed from within another definition that provided a suitable local frame. How you would manage that, or why you would want to, I leave up to you. Long story short: Access to parent locals is not sufficient to provide proper closures.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-09 12:27 -0500 |
| Message-ID | <XYydneTQgsRgrhzKnZ2dnUU7-RvNnZ2d@supernews.com> |
| In reply to | #48985 |
JennyB <jennybrien@googlemail.com> wrote: > On Saturday, 9 July 2016 15:01:08 UTC+1, Andrew Haley wrote: >> This is Forth. All of the usual rules still apply. If the object >> pointed to is still accessible (i.e. it is in data space) then it's >> valid. Why do you ask? > > That's why I said it would normally make no sense to execute a > quotation that references its parent's locals when the parent is no > longer in scope. The local reference doesn't capture a value, Ah, I see. It should, IMO. (FAOD: I'm not advocating closures in Forth because it's so very hard to figure out when the memory should be freed.) > Outside its parent, the quotation could only be meaningfully be > executed from within another definition that provided a suitable > local frame. How you would manage that, or why you would want to, I > leave up to you. Quite. I think that idea isn't going to fly. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-09 11:24 -0700 |
| Message-ID | <109ef13d-cae0-4715-9c73-1f831f6cf644@googlegroups.com> |
| In reply to | #48990 |
On Saturday, July 9, 2016 at 10:27:31 AM UTC-7, Andrew Haley wrote: > JennyB <jennybrien@googlemail.com> wrote: > > On Saturday, 9 July 2016 15:01:08 UTC+1, Andrew Haley wrote: > > >> This is Forth. All of the usual rules still apply. If the object > >> pointed to is still accessible (i.e. it is in data space) then it's > >> valid. Why do you ask? > > > > That's why I said it would normally make no sense to execute a > > quotation that references its parent's locals when the parent is no > > longer in scope. The local reference doesn't capture a value, > > Ah, I see. It should, IMO. (FAOD: I'm not advocating closures in > Forth because it's so very hard to figure out when the memory should > be freed.) You are not going to have closures in Forth because you don't have tagged data so you don't have any way of distinguishing between a pointer and an integer, so GC won't be able to figure out if there are any references remaining in use for a particular struct in the heap. Just use Lisp if you want this stuff. > > Outside its parent, the quotation could only be meaningfully be > > executed from within another definition that provided a suitable > > local frame. How you would manage that, or why you would want to, I > > leave up to you. > > Quite. I think that idea isn't going to fly. > > Andrew. LOL! Jennifer Brien has already figured out that this statement of her's is nonsense --- Andrew Haley (employee of Forth Inc.) had to go back to a post where she still didn't understand how quotations worked so he could agree with that. Quite (funny). The HOF doesn't have to "provide a suitable local frame" --- this was Jennifer's confused idea that the HOF had to have a look-alike local-frame as the parent function's --- actually, the HOF just has to have a local-frame so that its local-frame pointer can be held aside by REX (on the return-stack), but it doesn't matter to the quotation what the HOF's local-frame looks like because it is going to be ignored. Andrew Haley is just supporting Elizabeth Rather because he works for Forth Inc. and she is his boss. He doesn't actually know anything about the subject being discussed, or if he does know then he is playing dumb. He is the same guy who supported Elizabeth Rather when she spoke out against writing a code library to support full-duplex com in a UART and insisted that half-duplex should be used unless absolutely necessary, and that every application should include its own UART code that is totally optimized for the application. There is really no depth of idiocy that Elizabeth Rather could descend to and not have her employees support her --- this is true of every workplace --- this is why I don't want to work for Forth Inc. but prefer to work at a plumbing company where my boss knows plumbing (although he does occasionally make idiotic statements regarding other subjects, such as American history). Andrew Haley is a very loyal employee of Forth Inc. --- this is why Elizabeth Rather appointed him to the Forth-200x committee --- if you aren't a loyal employee of Forth Inc. then you can't be a voting member of the Forth-200x committee, so your opinion plus $1 will get you a cup of coffee... These are the voting members of the Forth-200x committee: Dr. Anton Ertl wrote gForth that is purposely crippled to be slower than SwiftForth Dr. Peter Knaggs works for MPE that does "joint projects" with Forth Inc. Willem Botha * Andrew Haley works for Forth Inc. Ulrich Hoffmanm * Simon Kaphahn * Bernd Paysan wrote gForth that is purposely crippled to be slower than SwiftForth Stephen Pelc the boss at MPE that does "joint projects" with Forth Inc. Dr. Willi Stricker * Leon Wagner the boss at Forth Inc. Gerald Wodni Of the 11 names, 4 are well-known to be working for Forth Inc.. Most likely, all of them are working for Forth Inc., but they keep this secret (I only know that Andrew Haley is a Forth Inc. employee because he bragged about it on comp.lang.forth, but he is not listed as such in the Forth-200x document). The 4 names with a * are interesting because they never show up during the Forth-200x discussions. The seem to have no interest in these discussions. I assume that they are just agents of Forth Inc. who were appointed to the committee so they could vote on the CfVs according to how Leon Wagner tells them to vote, but they don't have enough interest in the subject to participate in the discussions (they most likely don't even read the CfVs or RfDs). Alex McDonald has repeatedly said that he "does standards for a living." What does that mean? He put his name on this quotations RfD despite the fact that the RfD was pretty much a word-by-word copy of Stephen Pelc's article and despite the fact that the code was written by Bernd Paysan. It seems obvious that Alex McDonald's only contribution was to fake up the grassroots image of Forth-200x by making it appear that the RfD came from the Forth community rather than from the Forth-200x committee. When Alex McDonald claims that he "does standards for a living" I take this to mean that the Forth-200x committee pays him to put his name on their RfDs and pretend to represent the Forth community. I doubt that very much money can be made from doing standards for a living. This is why I assumed that Alex McDonald had been in jail when he disappeared. He reminds me of the ghetto monkeys who claim to be professional rappers but who actually make their living from welfare and shoplifting --- they tend to occasionally disappear for a few months of jail-time when they get caught stealing.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-30 02:03 -0700 |
| Message-ID | <7bd56f3b-cec2-4ded-b9ef-4974811937d8@googlegroups.com> |
| In reply to | #48985 |
On Saturday, July 9, 2016 at 7:40:41 AM UTC-7, JennyB wrote: > On Saturday, 9 July 2016 15:01:08 UTC+1, Andrew Haley wrote: > > mhx@iae.nl wrote: > > > What happens when a closure receives a pointer to something and > > > stores it in its locals. Can it depend on the object *pointed > > > to* being valid forever? > > > > This is Forth. All of the usual rules still apply. If the object > > pointed to is still accessible (i.e. it is in data space) then it's > > valid. Why do you ask? > > That's why I said it would normally make no sense to execute a quotation that references its parent's locals when the parent is no longer in scope. The local reference doesn't capture a value, it compiles a bit of code that says "fetch me what is at this offset from the address that on the local stack when I run" or something similar. So when it runs you've got to make sure the local stack points to a relevant address. Over on the Forth-200x mailing-list we have this rather humorous comment on the RfD from Bernd Paysan: On Fri, Jul 29, 2016 at 11:48:23PM +0200, Bernd Paysan bernd.paysan@gmx.de [forth200x] wrote: > Am Donnerstag, 28. Juli 2016, 18:55:50 CEST schrieb Anton Ertl > anton@mips.complang.tuwien.ac.at [forth200x]: > > System implementors are encouraged to provide support for > > accessing outer locals on an experimental basis so that programmers > > can explore the usefulness of this feature, possibly resulting in a > > proposal for this feature in the future. > > Be careful with that. If you, as system implementer, do this, only do it when > there is actually a local from the outer scope used inside the quotation. > Otherwise, it may not be possible to use one of those hook-setters where the > quotation outlives the scope of the surrounding word, like > > defer foo > > : make-bar [: ." bar" ;] is foo ; Thank you very much, Captain Obvious! Obviously, you can't have both a quotation that is both capable of outliving its parent and also of accessing its parent's locals. That is the fundamental distinction between :NONAME and my rquotations --- you get one feature or the other --- my rquotations are useful for implementing general-purpose data-structures, whereas :NONAME has been in ANS-Forth for over 20 years and has never been found to be useful for anything (most ANS-Forth programmers, including myself, have never written a program that used :NONAME for anything). This whole Paysan-faked-quotation RfD is just too funny!
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-07-09 14:36 +0000 |
| Message-ID | <2016Jul9.163629@mips.complang.tuwien.ac.at> |
| In reply to | #48983 |
mhx@iae.nl writes:
>On Saturday, July 9, 2016 at 2:30:33 PM UTC+2, Lars Brinkhoff wrote:
>> JennyB <jennybrien@googlemail.com> writes:
>> > there is normally is no sense in trying to access parent locals in
>> > that situation, when the parent is no longer in scope.
>>
>> I disagree. This is routinely done in many other languages. They're
>> usually called "closures". Whether it would be appropriate in Forth is
>> another matter, because it's a tradeoff between simplicity and
>> expressiveness.
>
>So what happens when I use this concept in a recursive word that
>calls other [ (mutually) recursive ] words? One of the called
>words could be EVALUATE . Is the full Forth system pushed
>on a big stack (in the cloud) somewhere, for each execution
>of the recursion?
The Forth system is not in a local, so there is no need to save it.
In particular, for EVALUATE, the reason why it's not a good idea to
use it for macros is because it uses the (global) state of the Forth
system (at run-time). If one could fully preserve the state at macro
definition time, and use that state at run-time, EVALUATE-based macros
would not be such a bad idea; of course, fully preserving the state
would be very expensive, and we have good alternatives that are much
less expensive.
>What happens when a closure receives a pointer to something and
>stores it in its locals. Can it depend on the object *pointed
>to* being valid forever?
In languages that support closures, yes, objects are valid (and
consume memory) as long as they are accessible, including being
accessible through closures. A typical implementation uses garbage
collection for both the closures and the objects, usually with some
optimization to allow stack allocation for many of those cases where
that is sufficient.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Håkan Thörngren <hth313@gmail.com> |
|---|---|
| Date | 2016-07-09 12:58 -0700 |
| Message-ID | <8333a285-82fa-425e-a3e4-ea330ebf85a3@googlegroups.com> |
| In reply to | #48645 |
On Friday, July 1, 2016 at 9:13:35 AM UTC-7, Anton Ertl wrote: > RfD: Quotations > --------------- [...] > > Syntax > ------ > > The following notations have been seen in the wild, oldest first. > :| ... |; > :[ ... ]: > [: ... ;] > > The notation [: ;] appears to have popular support. > Why do we need to invent new syntax (words) for this? Would it not be possible to just use the already existing :NONAME inside a definition? > 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. The intent should be that an inner definition shall be fully contained in its surrounding parent definition. This is at least what I would expect. Intermixing two different word definitions like this is confusing at best. Håkan
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-09 21:59 -0700 |
| Message-ID | <54b2cf0e-5043-40d2-b4e1-24bfcfe4f706@googlegroups.com> |
| In reply to | #48994 |
On Saturday, July 9, 2016 at 2:58:27 PM UTC-5, Håkan Thörngren wrote:
>
> Why do we need to invent new syntax (words) for this?
>
> Would it not be possible to just use the already existing :NONAME
> inside a definition?
>
:noname is already usable inside a definition. Where it has a
different meaning. So we can't use it again for this. It would have
to look something like
: foo ( -- )
0 IF [ :noname ." a" ; ] THEN LITERAL ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-09 23:11 -0700 |
| Message-ID | <bca9b1ab-a42f-45c6-99a1-7833ccbb0242@googlegroups.com> |
| In reply to | #48997 |
On Saturday, July 9, 2016 at 9:59:23 PM UTC-7, Julian Fondren wrote: > On Saturday, July 9, 2016 at 2:58:27 PM UTC-5, Håkan Thörngren wrote: > > > > Why do we need to invent new syntax (words) for this? > > > > Would it not be possible to just use the already existing :NONAME > > inside a definition? > > > > :noname is already usable inside a definition. Where it has a > different meaning. So we can't use it again for this. It would have > to look something like > > : foo ( -- ) > 0 IF [ :noname ." a" ; ] THEN LITERAL ; > > > -- Julian You don't test your code, do you Julien? Don't worry! So long as you brown-nose Elizabeth Rather, you still get to be considered an ANS-Forth programmer --- ANS-Forth is a cult --- writing code that works as never been required or even expected, but loyalty is demanded.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-07-10 00:14 -0700 |
| Message-ID | <f2a11998-57cc-47bf-ae2c-f132a0dd4dd1@googlegroups.com> |
| In reply to | #48998 |
On Sunday, July 10, 2016 at 1:11:06 AM UTC-5, hughag...@gmail.com wrote:
> On Saturday, July 9, 2016 at 9:59:23 PM UTC-7, Julian Fondren wrote:
> > :noname is already usable inside a definition. Where it has a
> > different meaning. So we can't use it again for this. It would have
> > to look something like
> >
> > : foo ( -- )
> > 0 IF [ :noname ." a" ; ] THEN LITERAL ;
> >
> >
> > -- Julian
>
> You don't test your code, do you Julien?
>
A native English speaker should pick up on the following indicators
that this code isn't expected to work as written. Starred:
It ***would have*** to look ***something like***
Contrast these definite statements:
As in:
It looks like this:
A person acting in good faith, as opposed to a lunatic starved for
even the smallest bits of meat that he can find or imagine, would
also have these indicators:
1. (I have several Forths and) this doesn't work in any of them
2. (I'm familiar with the standard and) this isn't at all
guaranteed at all to work
3. (I know Forth and) this obviously poses lots of problems that a
Forth implementation would have to work out.
It doesn't work, therefore, maybe, it's not intended to work, but
just to show what :NONAME-as-[: would have to look like? That makes
more sense, especially as the preceeding text is already explaining
that the following will not do:
: foo ( -- )
:noname ." a" ; then literal ;
\ ^ NOTE TO HUGH. THIS IS ALSO OBVIOUSLY WRONG
\ FOR EXAMPLE, THE DEFINITION ENDS AT THAT FIRST ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-07-12 01:06 -0700 |
| Message-ID | <b52420e9-a559-47e3-9ae3-1f0bfc5471b9@googlegroups.com> |
| In reply to | #49000 |
On Sunday, July 10, 2016 at 12:14:05 AM UTC-7, Julian Fondren wrote:
> On Sunday, July 10, 2016 at 1:11:06 AM UTC-5, hughag...@gmail.com wrote:
> > On Saturday, July 9, 2016 at 9:59:23 PM UTC-7, Julian Fondren wrote:
> > > :noname is already usable inside a definition. Where it has a
> > > different meaning. So we can't use it again for this. It would have
> > > to look something like
> > >
> > > : foo ( -- )
> > > 0 IF [ :noname ." a" ; ] THEN LITERAL ;
> > >
> > >
> > > -- Julian
> >
> > You don't test your code, do you Julien?
> >
>
> A native English speaker should pick up on the following indicators
> that this code isn't expected to work as written. Starred:
>
> It ***would have*** to look ***something like***
Actually, it would have to look something like this (in VFX):
variable pfq ok
: foo ahead [ :noname ." a" ; pfq ! ] then [ pfq @ ] literal ; ok
foo
Err# -13 ERR: Undefined word.
-> foo
^
And here it is in SwiftForth:
variable pfq ok
: foo ahead [ :noname ." a" ; pfq ! ] then [ pfq @ ] literal ; Unbalanced control structure
We can't leave the xt on the data-stack as Julian did. The control-stack may or may not be the data-stack, so we have to assume that the control-stack is the data-stack (in ANS-Forth it is always necessary to assume the worst-case scenario when given ambiguity), so the xt would get in the way of the AHEAD stuff that THEN needs. This is why I introduced the global variable PFQ (Paysan-faked quotation) to hold the xt temporarily while THEN executes.
Honestly, I don't really know why this doesn't work. ANS-Forth is pretty mysterious! Apparently MPE and Forth Inc. don't know "why" either, because they each say that it doesn't work for different reasons. In VFX the ; for FOO apparently doesn't unsmudge FOO --- most likely because it tries to unsmudge the last definition which isn't FOO --- but this doesn't make sense because the last definition was :NONAME which doesn't build a dictionary header, so it makes no sense that this is what ; would try to unsmudge. In SwiftForth we get an "unbalanced control structure" error --- but this doesn't make sense because the xt has been removed from the stack, so when THEN executes it should have the AHEAD stuff on the stack and be fine.
All in all, ANS-Forth is pretty mysterious --- I know more than most about ANS-Forth, yet I find it quite baffling --- I can't predict whether any particular ANS-Forth code is going to work or not, so I just have to experiment, but even if I get some ANS-Forth code to work on some ANS-Forth compilers I have no guarantee that it will work on some other ANS-Forth compilers that I haven't tested it on yet (or on future versions of the ANS-Forth compilers that I did test it on).
My own VFX and SwiftForth code that I provided earlier, and which when tested did work, is not guaranteed to continue working in future versions of VFX and SwiftForth --- for one thing, an optimizing compiler might discard all of the code between AHEAD and THEN as being dead code that can't be reached --- Leon Wagner and Stephen Pelc might do this on purpose to make my code stop working, then say that it was my fault for writing non-standard code --- that would really pull the rug out from under my feet, especially if people had written large commercial programs that relied on my code, forcing them to stick with an obsolete version of the compiler so their program will continue to work.
ANS-Forth is a mess. It is not ready for prime-time in the sense that it could be used professionally for commercial programs --- there are too many pitfalls, gotchas and baffling mysteries--- it is only suitable for toy programs (Anton Ertl's homework assignments).
[toc] | [prev] | [next] | [standalone]
| From | JennyB <jennybrien@googlemail.com> |
|---|---|
| Date | 2016-07-12 05:31 -0700 |
| Message-ID | <f76c5858-35f0-4d01-ba54-beacf1db709e@googlegroups.com> |
| In reply to | #49072 |
> variable pfq ok > : foo ahead [ :noname ." a" ; pfq ! ] then [ pfq @ ] literal ; ok > foo > Err# -13 ERR: Undefined word. > -> foo > ^ > > And here it is in SwiftForth: > > variable pfq ok > : foo ahead [ :noname ." a" ; pfq ! ] then [ pfq @ ] literal ; Unbalanced control structure > > > Honestly, I don't really know why this doesn't work. ANS-Forth is pretty mysterious! Apparently MPE and Forth Inc. don't know "why" either, because they each say that it doesn't work for different reasons. In VFX the ; for FOO apparently doesn't unsmudge FOO --- most likely because it tries to unsmudge the last definition which isn't FOO --- but this doesn't make sense because the last definition was :NONAME which doesn't build a dictionary header, so it makes no sense that this is what ; would try to unsmudge. In SwiftForth we get an "unbalanced control structure" error --- but this doesn't make sense because the xt has been removed from the stack, so when THEN executes it should have the AHEAD stuff on the stack and be fine. Julian was not saying it would or should work, only that if we want quotations we need both :NONAME and [: . There may be some Forth's on which it does work, but it should not be expected. It leaves two definitions open at the same time, so how does : know which to close? It is not designed to deal with nested definitions. Knowing that, perhaps the simplest method of implementing : is to have it sotre the address of the header in a global variable, which ; can use later to make it visible. It does not need to be re-entrant. The sinmplest way to implement :NONAME then is to store the address of a dummy header which can be harmlessly 'revealed.' The code for ; does not need to alter. As you say yourself, the programmer should only have to deal with the interface, not the nuts and bolts. The interface is clearly that ; only has to deal with one open definition. So, assuming the implementation to be something like the above: The :NONAME compiles correctly, but at this stage the address of Foo's header is lost, so it cannot be unsmudged. In VFX the whole definition compiles, but Foo remains hidden. SwiftForth has more compiler security. I expect it distinguishes between colon-sys left by : and colon-sys left by :NONAME The final ; sees the discrepency (a header expected but an invalid address) and throws a control structure error. > My own VFX and SwiftForth code that I provided earlier, and which when tested did work, is not guaranteed to continue working in future versions of VFX and SwiftForth --- for one thing, an optimizing compiler might discard all of the code between AHEAD and THEN as being dead code that can't be reached --- Leon Wagner and Stephen Pelc might do this on purpose to make my code stop working, then say that it was my fault for writing non-standard code. What a compiler does with code that does not conform to the published interface is entirely up to the compiler writer. The standard is the interface, not the nuts and bolts of the compiler code. That's the way it has to be if code is to run on more than compiler. And that's why compiler writers don't like to talk about implementation-specific details - if people program to the implementation rather than the interface, and feel justified in complaining when their code breaks, then the compiler cannot evolve.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web