Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #7710 > unrolled thread
| Started by | Arnold Doray <thinksquared@gmail.com> |
|---|---|
| First post | 2011-12-03 19:07 +0000 |
| Last post | 2011-12-08 03:37 -0600 |
| Articles | 20 on this page of 187 — 17 participants |
Back to article view | Back to comp.lang.forth
Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-03 19:07 +0000
Re: Memoizing recursive words "A. K." <akk@nospam.org> - 2011-12-04 13:21 +0100
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-04 14:20 +0000
Re: Memoizing recursive words Josh Grams <josh@qualdan.com> - 2011-12-04 16:03 +0000
Re: Memoizing recursive words "A. K." <akk@nospam.org> - 2011-12-04 17:25 +0100
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-04 10:51 -0800
Re: Memoizing recursive words "Elizabeth D. Rather" <erather@forth.com> - 2011-12-04 12:50 -1000
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-04 15:40 -0800
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-05 11:17 +0000
Re: Memoizing recursive words "Elizabeth D. Rather" <erather@forth.com> - 2011-12-04 08:24 -1000
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-04 19:14 +0000
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-04 12:09 -0800
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-05 04:00 +0000
Re: Memoizing recursive words BruceMcF <agila61@netscape.net> - 2011-12-07 12:41 -0800
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-05 11:04 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 07:24 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 04:02 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 08:03 +0000
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-06 10:46 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 04:54 -0600
Re: Memoizing recursive words Hans Bezemer <thebeez@xs4all.nl> - 2011-12-08 00:08 +0100
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 12:36 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 10:28 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 16:32 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 10:40 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-06 16:51 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-06 12:03 -0600
Re: Memoizing recursive words Hans Bezemer <thebeez@xs4all.nl> - 2011-12-07 23:55 +0100
Re: Memoizing recursive words Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-07 01:06 +0100
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 03:37 -0600
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-07 10:36 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 06:23 -0600
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-07 13:50 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 11:49 -0600
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 15:36 +0000
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 16:15 +0000
Re: Memoizing recursive words Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-12-10 17:23 +0000
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-10 17:34 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 11:43 -0600
return address manipulation (was: Memoizing recursive words) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-07 13:29 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 11:55 -0600
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-08 00:03 +0100
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-07 15:11 -0800
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-08 01:52 +0100
Re: return address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-08 11:12 +0000
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-08 18:04 +0100
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-08 15:51 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-08 12:17 -0600
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-13 13:07 -0600
Re: return address manipulation Alex McDonald <blog@rivadpm.com> - 2011-12-13 13:37 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 03:45 -0600
Re: return address manipulation Alex McDonald <blog@rivadpm.com> - 2011-12-14 01:58 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 04:09 -0600
Re: return address manipulation "Elizabeth D. Rather" <erather@forth.com> - 2011-12-14 10:43 -1000
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-14 14:08 +0100
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 09:18 -0600
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 09:48 -0600
Re: return address manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-14 23:24 +0100
Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 04:50 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 07:45 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 15:48 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 08:08 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 10:44 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:07 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 17:16 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:44 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 17:55 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 10:13 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:24 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 11:25 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:40 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 12:11 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 19:01 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 03:14 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-16 07:54 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 16:58 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-17 09:58 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-19 14:36 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-19 12:49 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-20 02:55 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-20 06:34 -0800
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 10:22 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 12:44 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:27 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 09:33 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 12:52 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-15 11:07 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 03:16 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-16 08:10 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 12:38 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-16 08:13 -0800
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 12:43 -0600
Re: Quotations [Was: return address manipulation] Sieur de Bienville <morrimichael@gmail.com> - 2011-12-17 15:35 -0800
Re: Quotations [Was: return address manipulation] Roelf Toxopeus <rt4all@notthis.hetnet.nl> - 2011-12-19 20:40 +0100
Re: Quotations [Was: return address manipulation] Sieur de Bienville <morrimichael@gmail.com> - 2011-12-19 13:41 -0800
Re: Quotations [Was: return address manipulation] Mark Wills <markrobertwills@yahoo.co.uk> - 2011-12-27 07:30 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-27 16:21 +0000
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-27 20:55 +0100
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-27 14:42 -0600
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-27 22:58 +0100
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-27 16:43 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 12:00 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-30 06:09 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 13:23 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-30 08:13 -0600
Re: Quotations [Was: return address manipulation] mhx@iae.nl (Marcel Hendrix) - 2011-12-30 16:48 +0200
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-30 16:36 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2011-12-30 15:16 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-31 14:00 +0000
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-01 12:22 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 06:09 -0600
Re: Quotations [Was: return address manipulation] mhx@iae.nl (Marcel Hendrix) - 2012-01-01 14:17 +0200
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 09:50 -0600
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2012-01-01 18:15 +0100
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 11:48 -0600
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-02 11:19 +0000
Re: Quotations [Was: return address manipulation] mhx@iae.nl (Marcel Hendrix) - 2012-01-01 14:02 +0200
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-01 09:37 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-02 14:30 +0000
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-03 13:28 +0000
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2012-01-01 13:35 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-02 14:14 +0000
Re: Quotations [Was: return address manipulation] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-01-03 12:04 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-31 14:19 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-31 11:46 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-02 13:47 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-02 10:19 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-03 09:08 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-03 04:47 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-03 16:55 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-03 11:28 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 14:52 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 09:54 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 17:28 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 12:10 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2012-01-03 10:09 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 17:14 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 11:26 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 17:49 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 12:11 -0600
Re: Quotations [Was: return address manipulation] BruceMcF <agila61@netscape.net> - 2012-01-04 12:59 -0800
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-05 16:46 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-03 16:34 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-03 11:40 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-04 15:03 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-01-04 12:01 -0600
Re: Quotations [Was: return address manipulation] Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-01-04 21:02 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-01-05 16:38 +0000
Re: Quotations [Was: return address manipulation] Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-01-07 14:27 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 11:33 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-30 11:53 +0000
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-16 17:18 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-16 13:16 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-19 15:01 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-15 10:40 -0600
Re: Quotations [Was: return address manipulation] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-22 16:21 +0000
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-22 11:40 -0600
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-26 13:01 -0600
Re: Quotations [Was: return address manipulation] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-27 03:54 -0600
Re: Quotations [Was: return address manipulation] Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-15 20:11 +0100
Quotations (was: return address manipulation) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-14 15:27 +0000
Re: Quotations Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-14 09:50 -0600
Re: Quotations Bernd Paysan <bernd.paysan@gmx.de> - 2011-12-14 22:38 +0100
Re: Quotations Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-12-14 23:03 +0000
Re: Quotations anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-15 15:56 +0000
Re: return address manipulation stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-09 14:48 +0000
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-09 16:35 +0000
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-09 10:18 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-09 12:36 -0600
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-09 12:07 -0800
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:37 +0000
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 11:49 -0600
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-10 10:06 -0800
Re: return address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-10 12:37 -0600
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-10 11:28 -0800
Re: return address manipulation "Elizabeth D. Rather" <erather@forth.com> - 2011-12-09 08:39 -1000
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-10 12:34 +0000
Re: return address manipulation BruceMcF <agila61@netscape.net> - 2011-12-10 06:39 -0800
Re: return address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-11 11:30 +0000
Re: Memoizing recursive words stephenXXX@mpeforth.com (Stephen Pelc) - 2011-12-06 17:18 +0000
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-07 14:30 +0000
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-07 15:33 +0000
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-07 17:09 +0000
Re: Memoizing recursive words anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-12-07 17:26 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-07 12:08 -0600
Re: Memoizing recursive words Arnold Doray <thinksquared@gmail.com> - 2011-12-08 00:05 +0000
Re: Memoizing recursive words Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-12-08 03:37 -0600
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-07 11:55 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <OvadnU1Pp7QENULTnZ2dnUVZ_rydnZ2d@supernews.com> |
| In reply to | #7783 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > There is also the issue of processors that put the return addresses > in a place that is not accessible as data, but I doubt that Forth > implementations for these CPUs are fully compliant anyway, so if we > standardized return-address manipulation, that would be just one > standard feature among several that such a system does not > implement. That isn't necessarily true. > The uses of return-address manipulation I have seen from Bernd can be > replaced without too much effort with quotations (nested variants of > :NONAME words) and words that take xts. Some of the things Michael > Gassanenko has done may be harder to replace (not sure). > > Overall, I think that we should add quotations and use them to replace > return-address manipulating code. Then the compiler can happily > perform inlining and tail-call optimization. I've wanted this for, oh, ages. It would make the language considerably more powerful, but there's not much common practice in this area. And I'm not sure how much actual use it'd get in Forth's user base: I'm against adding any more dusty corners to the language. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-08 00:03 +0100 |
| Subject | Re: return address manipulation |
| Message-ID | <jborbb$1cm$1@online.de> |
| In reply to | #7791 |
Andrew Haley wrote:
>> Overall, I think that we should add quotations and use them to
>> replace
>> return-address manipulating code. Then the compiler can happily
>> perform inlining and tail-call optimization.
>
> I've wanted this for, oh, ages. It would make the language
> considerably more powerful, but there's not much common practice in
> this area. And I'm not sure how much actual use it'd get in Forth's
> user base: I'm against adding any more dusty corners to the language.
MINOS heavily relies on quotations. I feel a bit guilty of using return
stack tricks in MINOS, where the quotations would do that job, too, and
the MINOS harness actually provides these quotations (and all the fancy
OOP stuff to do real iterators and so on), but those return stack
manipulation parts are historical, as the quotations became obvious and
essential not before I did Theseus, the GUI editor.
People who edit a GUI want to enter the actions a button does, but do
not want to give these actions a name. An unnamed definition however is
only identified by its position, so it's right where you use it, i.e. it
has to be a quotation. For more direct usages of quotations in Forth you
can use named words, and tick those.
The definition of my quotations are fairly portable, this is how it
looks like in bigForth (factored a bit more for clairty):
: comp-state@ ( -- state ) loffset @ last @ ;
: comp-state! ( state -- ) last ! loffset ! ;
: :[ ( compile-time: -- orig colon-sys )
state @ IF comp-state@ POSTPONE AHEAD true
ELSE false THEN
:noname ; immediate
: ]: ( compile-time: orig colon-sys -- ; run-time: -- xt )
POSTPONE ; >r IF ] comp-state! POSTPONE THEN r> POSTPONE ALiteral
ELSE r> THEN ( xt ) ; immediate
What differs between different Forth systems is what you need to save
and restore in comp-state@ and comp-state!.
Since all single braces are used up, I decided to have :[ ]: as
delimiters (the colon shows that this stuff inside a quotation is a
definition, i.e. compiled).
Retro uses single [ ] for quotations, but Retro choses to ignore most of
standard Forth ;-). Another obvious syntax would be '[ ]'.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-07 15:11 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <358a91ef-ac8b-4157-9135-7d50dd80b5d2@l24g2000yqm.googlegroups.com> |
| In reply to | #7804 |
On Dec 7, 6:03 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: > Since all single braces are used up, I decided to have :[ ]: as > delimiters (the colon shows that this stuff inside a quotation is a > definition, i.e. compiled). Do quotations nest? If so, [: ... ;] would be reasonably pictographic (as well as being happier emoticons than the grumpy ones you picked). In any event, I like :[ ... ]: best of the three mentioned.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-08 01:52 +0100 |
| Subject | Re: return address manipulation |
| Message-ID | <jbp1oe$5b2$1@online.de> |
| In reply to | #7806 |
BruceMcF wrote: > On Dec 7, 6:03 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote: >> Since all single braces are used up, I decided to have :[ ]: as >> delimiters (the colon shows that this stuff inside a quotation is a >> definition, i.e. compiled). > > Do quotations nest? Of course. > If so, [: ... ;] would be reasonably pictographic > (as well as being happier emoticons than the grumpy ones you picked). Knode translates :[ into a vampire bat ;-). I actually like [: and ;], and wonder why I haven't picked those. Idiomatic, they make a lot more sense than my :[ ]:, because enclosing something in brackets means "at compile time", and enclosing an entire definition with brackets thus means "nested definion". Just that there is no name. > In any event, I like :[ ... ]: best of the three mentioned. [ ] is already taken, it's not available. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2011-12-08 11:12 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <jbq628$hj$1@dont-email.me> |
| In reply to | #7810 |
On 08/12/2011 00:52, Bernd Paysan wrote: > BruceMcF wrote: > >> On Dec 7, 6:03 pm, Bernd Paysan<bernd.pay...@gmx.de> wrote: >>> Since all single braces are used up, I decided to have :[ ]: as >>> delimiters (the colon shows that this stuff inside a quotation is a >>> definition, i.e. compiled). >> >> Do quotations nest? > > Of course. > >> If so, [: ... ;] would be reasonably pictographic >> (as well as being happier emoticons than the grumpy ones you picked). > > Knode translates :[ into a vampire bat ;-). I actually like [: and ;], > and wonder why I haven't picked those. Idiomatic, they make a lot more > sense than my :[ ]:, because enclosing something in brackets means "at > compile time", and enclosing an entire definition with brackets thus > means "nested definion". Just that there is no name. Yes I use [: ... ;] for that very reason. > >> In any event, I like :[ ... ]: best of the three mentioned. > > [ ] is already taken, it's not available. > -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-08 18:04 +0100 |
| Subject | Re: return address manipulation |
| Message-ID | <jbqqm8$qqm$1@online.de> |
| In reply to | #7826 |
Gerry Jackson wrote: >> Knode translates :[ into a vampire bat ;-). I actually like [: and >> ;], and wonder why I haven't picked those. Idiomatic, they make a >> lot more sense than my :[ ]:, because enclosing something in brackets >> means "at compile time", and enclosing an entire definition with >> brackets thus means "nested definion". Just that there is no name. > > Yes I use [: ... ;] for that very reason. I'd say we have a consensus on which smiley to use ;-). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-08 15:51 +0000 |
| Subject | Re: return address manipulation |
| Message-ID | <2011Dec8.165153@mips.complang.tuwien.ac.at> |
| In reply to | #7791 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>> There is also the issue of processors that put the return addresses
>> in a place that is not accessible as data, but I doubt that Forth
>> implementations for these CPUs are fully compliant anyway, so if we
>> standardized return-address manipulation, that would be just one
>> standard feature among several that such a system does not
>> implement.
>
>That isn't necessarily true.
Please elaborate! Do you know of any standard systems on CPUs where
the return addresses cannot be accessed as data? Or at least of CPUs
large enough for standard systems that have such a restriction?
>> Overall, I think that we should add quotations and use them to replace
>> return-address manipulating code. Then the compiler can happily
>> perform inlining and tail-call optimization.
>
>I've wanted this for, oh, ages. It would make the language
>considerably more powerful, but there's not much common practice in
>this area. And I'm not sure how much actual use it'd get in Forth's
>user base: I'm against adding any more dusty corners to the language.
Then I guess that way to go is to add it to some systems and establish
some common practice.
Given that return address manipulation is common enough that VFX even
foregoes some optimizations to support it, quotations might gain some
usage once the systems have provided them for a few years.
- 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 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-08 12:17 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <If2dnZAUYMzJYn3TnZ2dnUVZ_v2dnZ2d@supernews.com> |
| In reply to | #7833 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >> >>> There is also the issue of processors that put the return addresses >>> in a place that is not accessible as data, but I doubt that Forth >>> implementations for these CPUs are fully compliant anyway, so if we >>> standardized return-address manipulation, that would be just one >>> standard feature among several that such a system does not >>> implement. >> >>That isn't necessarily true. > > Please elaborate! Do you know of any standard systems on CPUs where > the return addresses cannot be accessed as data? Or at least of > CPUs large enough for standard systems that have such a restriction? An 8051 has enough address space and has an internal subroutine stack that's used for return addresses only. I don't know if the Forth, Inc version supports all of CORE, but it could, which is the point. >>> Overall, I think that we should add quotations and use them to replace >>> return-address manipulating code. Then the compiler can happily >>> perform inlining and tail-call optimization. >> >>I've wanted this for, oh, ages. It would make the language >>considerably more powerful, but there's not much common practice in >>this area. And I'm not sure how much actual use it'd get in Forth's >>user base: I'm against adding any more dusty corners to the language. > > Then I guess that way to go is to add it to some systems and establish > some common practice. > > Given that return address manipulation is common enough that VFX even > foregoes some optimizations to support it, quotations might gain some > usage once the systems have provided them for a few years. Maybe. I'll have a look at what it would take to do it in SwiftForth. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-13 13:07 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <6MqdnZRLdI0XP3rTnZ2dnUVZ_u6dnZ2d@supernews.com> |
| In reply to | #7839 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>
>>>> Overall, I think that we should add quotations and use them to replace
>>>> return-address manipulating code. Then the compiler can happily
>>>> perform inlining and tail-call optimization.
>>>
>>>I've wanted this for, oh, ages. It would make the language
>>>considerably more powerful, but there's not much common practice in
>>>this area. And I'm not sure how much actual use it'd get in Forth's
>>>user base: I'm against adding any more dusty corners to the language.
>>
>> Then I guess that way to go is to add it to some systems and establish
>> some common practice.
>>
>> Given that return address manipulation is common enough that VFX even
>> foregoes some optimizations to support it, quotations might gain some
>> usage once the systems have provided them for a few years.
>
> Maybe. I'll have a look at what it would take to do it in SwiftForth.
Turns out it's pretty easy on x86 SwiftForth, but not exactly trivial:
icode (quotation)
here $400 + call
ret end-code
: [: postpone (quotation) postpone begin ; immediate
: ;] postpone exit postpone then
postpone r> postpone code> ; immediate
This takes advantage of the fact that the return stack really is the
processor's return stack and the rather nice ICODE allows the easy
insertion of assembly language fragments. It even generates pretty
efficient code. RECURSE doesn't work properly, though; is that a
problem? Do we even know what RECURSE should to inside a quotation?
The capture of locals' values would be nice to have, but perhaps
that's rather too much.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-12-13 13:37 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <41e6a564-bf17-4ed6-9502-7f240b49c9aa@4g2000yqu.googlegroups.com> |
| In reply to | #8045 |
On Dec 13, 7:07 pm, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > > Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: > >> Andrew Haley <andre...@littlepinkcloud.invalid> writes: > >>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote: > > >>>> Overall, I think that we should add quotations and use them to replace > >>>> return-address manipulating code. Then the compiler can happily > >>>> perform inlining and tail-call optimization. > > >>>I've wanted this for, oh, ages. It would make the language > >>>considerably more powerful, but there's not much common practice in > >>>this area. And I'm not sure how much actual use it'd get in Forth's > >>>user base: I'm against adding any more dusty corners to the language. > > >> Then I guess that way to go is to add it to some systems and establish > >> some common practice. > > >> Given that return address manipulation is common enough that VFX even > >> foregoes some optimizations to support it, quotations might gain some > >> usage once the systems have provided them for a few years. > > > Maybe. I'll have a look at what it would take to do it in SwiftForth. > > Turns out it's pretty easy on x86 SwiftForth, but not exactly trivial: > > icode (quotation) > here $400 + call > ret end-code > > : [: postpone (quotation) postpone begin ; immediate > : ;] postpone exit postpone then > postpone r> postpone code> ; immediate > > This takes advantage of the fact that the return stack really is the > processor's return stack and the rather nice ICODE allows the easy > insertion of assembly language fragments. It even generates pretty > efficient code. RECURSE doesn't work properly, though; is that a > problem? Do we even know what RECURSE should to inside a quotation? > > The capture of locals' values would be nice to have, but perhaps > that's rather too much. > > Andrew. Does Swiftforth have only one data space?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-14 03:45 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <us2dnQ3YAfKk7XXTnZ2dnUVZ_oednZ2d@supernews.com> |
| In reply to | #8048 |
Alex McDonald <blog@rivadpm.com> wrote: > > Does Swiftforth have only one data space? I don't really know what you mean. I'm pretty sure that the processor has only one data space. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-12-14 01:58 -0800 |
| Subject | Re: return address manipulation |
| Message-ID | <7f6ea3d6-8f21-4f23-8ebb-a6fabae878e5@f33g2000yqh.googlegroups.com> |
| In reply to | #8058 |
On Dec 14, 9:45 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Alex McDonald <b...@rivadpm.com> wrote: > > > Does Swiftforth have only one data space? > > I don't really know what you mean. I'm pretty sure that the processor > has only one data space. > > Andrew. ANS Forth; "data space: The logical area of the dictionary that can be accessed." Some Forths maintain separate code and data spaces. Which type is SwiftForth?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-14 04:09 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <r5OdneCtT7J36HXTnZ2dnUVZ_tidnZ2d@supernews.com> |
| In reply to | #8059 |
Alex McDonald <blog@rivadpm.com> wrote: > On Dec 14, 9:45?am, Andrew Haley <andre...@littlepinkcloud.invalid> > wrote: >> Alex McDonald <b...@rivadpm.com> wrote: >> >> > Does Swiftforth have only one data space? >> >> I don't really know what you mean. ?I'm pretty sure that the processor >> has only one data space. > > ANS Forth; "data space: The logical area of the dictionary that can be > accessed." Some Forths maintain separate code and data spaces. Which > type is SwiftForth? Oh, I see. Just the one, I think. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2011-12-14 10:43 -1000 |
| Subject | Re: return address manipulation |
| Message-ID | <-bqdnZUDobPxl3TTnZ2dnUVZ_o2dnZ2d@supernews.com> |
| In reply to | #8061 |
On 12/14/11 12:09 AM, Andrew Haley wrote: > Alex McDonald<blog@rivadpm.com> wrote: >> On Dec 14, 9:45?am, Andrew Haley<andre...@littlepinkcloud.invalid> >> wrote: >>> Alex McDonald<b...@rivadpm.com> wrote: >>> >>>> Does Swiftforth have only one data space? >>> >>> I don't really know what you mean. ?I'm pretty sure that the processor >>> has only one data space. >> >> ANS Forth; "data space: The logical area of the dictionary that can be >> accessed." Some Forths maintain separate code and data spaces. Which >> type is SwiftForth? > > Oh, I see. Just the one, I think. Code and data space are integrated in SwiftForth. They are segregated in SwiftX targets, though: code space plus initialized and uninitialized data space. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-14 14:08 +0100 |
| Subject | Re: return address manipulation |
| Message-ID | <jca74j$o1f$1@online.de> |
| In reply to | #8045 |
Andrew Haley wrote: > Turns out it's pretty easy on x86 SwiftForth, but not exactly trivial: > > icode (quotation) > here $400 + call > ret end-code > > : [: postpone (quotation) postpone begin ; immediate > : ;] postpone exit postpone then > postpone r> postpone code> ; immediate > > This takes advantage of the fact that the return stack really is the > processor's return stack and the rather nice ICODE allows the easy > insertion of assembly language fragments. It even generates pretty > efficient code. RECURSE doesn't work properly, though; is that a > problem? Do we even know what RECURSE should to inside a quotation? Probably recurse the nested definition. > The capture of locals' values would be nice to have, but perhaps > that's rather too much. Ah, no closures. Just nested anonymous definitions. What would be nice is when the nested definition could have their own locals. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-14 09:18 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <c_Kdnf-g5PWwI3XTnZ2dnUVZ_rqdnZ2d@supernews.com> |
| In reply to | #8062 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: >> Turns out it's pretty easy on x86 SwiftForth, but not exactly trivial: >> >> icode (quotation) >> here $400 + call >> ret end-code >> >> : [: postpone (quotation) postpone begin ; immediate >> : ;] postpone exit postpone then >> postpone r> postpone code> ; immediate >> >> This takes advantage of the fact that the return stack really is the >> processor's return stack and the rather nice ICODE allows the easy >> insertion of assembly language fragments. It even generates pretty >> efficient code. RECURSE doesn't work properly, though; is that a >> problem? Do we even know what RECURSE should to inside a quotation? > > Probably recurse the nested definition. Ouch. I think that's going to make it harder. >> The capture of locals' values would be nice to have, but perhaps >> that's rather too much. > > Ah, no closures. Just nested anonymous definitions. Shame. :-) But the really evil problem with locals is that it really requires garbage collection: there's no way to know when a closure is no longer needed. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-14 09:48 -0600 |
| Subject | Re: return address manipulation |
| Message-ID | <ZcOdnY-D6fj6WHXTnZ2dnUVZ_jOdnZ2d@supernews.com> |
| In reply to | #8065 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> Andrew Haley wrote:
>>> Turns out it's pretty easy on x86 SwiftForth, but not exactly trivial:
>>>
>>> icode (quotation)
>>> here $400 + call
>>> ret end-code
>>>
>>> : [: postpone (quotation) postpone begin ; immediate
>>> : ;] postpone exit postpone then
>>> postpone r> postpone code> ; immediate
>>>
>>> This takes advantage of the fact that the return stack really is the
>>> processor's return stack and the rather nice ICODE allows the easy
>>> insertion of assembly language fragments. It even generates pretty
>>> efficient code. RECURSE doesn't work properly, though; is that a
>>> problem? Do we even know what RECURSE should to inside a quotation?
>>
>> Probably recurse the nested definition.
>
> Ouch. I think that's going to make it harder.
Oh, it's not so bad:
: [: last 2 cells + @ \ Save last code address
postpone (quotation) postpone begin
here last 2 cells + ! \ Last code address points to our quotation
; immediate
: ;] postpone exit
postpone then \ Branch over the quotation
last 2 cells + ! \ Restore last code address
postpone r> postpone code> ; immediate
And for a rather contrived test case:
: factorial ( n) ( f: - r)
[: ( n - xt) ( f: - r)
s>f
[: ( f: r - r')
f?dup if
fdup 1.0e f- recurse f*
else 1.0e0 then
;]
;]
execute execute ;
69 factorial fe. 171.12245E+96 ok
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-14 23:24 +0100 |
| Subject | Re: return address manipulation |
| Message-ID | <jcb7nc$i8k$1@online.de> |
| In reply to | #8068 |
Andrew Haley wrote:
> And for a rather contrived test case:
>
> : factorial ( n) ( f: - r)
> [: ( n - xt) ( f: - r)
> s>f
> [: ( f: r - r')
> f?dup if
> fdup 1.0e f- recurse f*
> else 1.0e0 then
> ;]
> ;]
> execute execute ;
>
> 69 factorial fe.
Apart from the f?dup and the floating point stack depth limits, this
works out of the box in bigForth, so I got that right by design.
This is my contrieved test case variation: It uses the floating point
stack only for the output.
: factorial ( n) ( f: - r)
[: ( n - xt) ( f: - r)
1e0
[: ( f: r - r')
?dup if
dup 1 - recurse s>f f*
then
;]
;]
execute execute ;
69 factorial fe.
BTW: the intra-word forward call you are using to jump over the
quotation is something I use in my regexp compiler.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-15 04:50 -0600 |
| Subject | Quotations [Was: return address manipulation] |
| Message-ID | <LvWdnac1IqFwTXTTnZ2dnUVZ_qidnZ2d@supernews.com> |
| In reply to | #8062 |
Bernd Paysan <bernd.paysan@gmx.de> wrote: > Andrew Haley wrote: > >> The capture of locals' values would be nice to have, but perhaps >> that's rather too much. > > Ah, no closures. Just nested anonymous definitions. What would be nice > is when the nested definition could have their own locals. I've had a look at this, and it's not always going to be easy: you'd have to be able add some names to the locals list and strip them back at the end of each quotation. I guess this is easy enough when locals are implemented using a private wordlist -- you can just use MARKER . But otherwise it might be rather tricky. Is this important, do you think? I can't make my mind up. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2011-12-15 07:45 -0800 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <8a9b576c-31e1-405f-bad3-9c2171cdf339@h11g2000yqd.googlegroups.com> |
| In reply to | #8086 |
On Dec 15, 5:50 am, Andrew Haley <andre...@littlepinkcloud.invalid> wrote: > Bernd Paysan <bernd.pay...@gmx.de> wrote: > > Andrew Haley wrote: > > >> The capture of locals' values would be nice to have, but perhaps > >> that's rather too much. > > > Ah, no closures. Just nested anonymous definitions. What would be nice > > is when the nested definition could have their own locals. > > I've had a look at this, and it's not always going to be easy: you'd > have to be able add some names to the locals list and strip them back > at the end of each quotation. I guess this is easy enough when locals > are implemented using a private wordlist -- you can just use MARKER . > But otherwise it might be rather tricky. > > Is this important, do you think? I can't make my mind up. Couldn't it just be specified that the local names within each quotation should be unique within each containing definition, and use of local names not defined within a quotation is an ambiguous condition?
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web