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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-01-04 12:59 -0800 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <82bca416-d222-465d-a938-1c86f6a8626e@q8g2000yqa.googlegroups.com> |
| In reply to | #8655 |
On Jan 4, 12:14 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > It's definitely a loss. Re-entrancy is easy with ordinary closures, > so Andrew's closures are not a step towards re-entrancy. I'm sure I would have not idea what ordinary closures would be as distinct from extraordinary closures without a preceding "ordinary closure:" label. I'm only curious what the upside is. > And re-entrancy is not the only desirable feature. If every feature > that allows us to write non-re-entrant code was eliminated, we would > not have, e.g., "!". Be we already have ! so the ability to have it does not need to be replicated. As far as re-entrancy, I can start to dimly see an upside of being able to hand a closure off to a background task I start up and when I have got all of my task's work done, going to sleep until one of the tasks has got a result closure to hand back to me.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-05 16:46 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan5.174658@mips.complang.tuwien.ac.at> |
| In reply to | #8664 |
BruceMcF <agila61@netscape.net> writes:
>On Jan 4, 12:14=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>
>> It's definitely a loss. =A0Re-entrancy is easy with ordinary closures,
>> so Andrew's closures are not a step towards re-entrancy.
...
>I'm only curious what the upside is.
The upside of ordinary closures over Andrew's closures is that you can
use some of the cool techniques that Algol 60, Pascal, and
particularly Scheme programmers have thought up. And there's no
downside, because everything that you can do with Andrew's closures
can be done with ordinary closures, too.
>> And re-entrancy is not the only desirable feature. =A0If every feature
>> that allows us to write non-re-entrant code was eliminated, we would
>> not have, e.g., "!".
>
>Be we already have ! so the ability to have it does not need to be
>replicated.
Mutable outer locals don't replicate "!". My point was this: We
already have features that make it possible to write non-re-entrant
code, so eliminating a feature because it allows you to write such
code is water down the river.
>As far as re-entrancy, I can start to dimly see an upside of being
>able to hand a closure off to a background task I start up and when I
>have got all of my task's work done, going to sleep until one of the
>tasks has got a result closure to hand back to me.
Passing closures with mutable shared data to other tasks is exactly
the case where we can get race conditions because of non-re-entrancy,
so one usually will want to avoid that, and if not, be careful what
you are doing. I expect that one would normally use only read-only
shared data for closures that are passed to another task, and use
mutable shared data only for closures used within a single task.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-03 16:34 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan3.173454@mips.complang.tuwien.ac.at> |
| In reply to | #8621 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
[...]
>: z { x } [: ( xt -- n ) execute x 1+ to x x . ;] ;
>z constant w
>:noname ; ['] w ['] w execute
>
>Here you have one closure, w (i.e, only one copy of x) and two nested
>executions.
>
>>In what sense is one closure "ordinary" and one not? In something
>>like pure LISP (or indeed, the lambda calculus) you only have values.
>
>It's what languages with closures have done for decades, starting with
>Scheme and lexically scoped LISPs.
Even earlier, languages with nested procedures such as Algol 60 and
Pascal behaved this way; they did not have first-class closures, but
what they had is enough to mix recursion, outer local references, and
updates. E.g., the example above can be adapted to use only the
features available in Pascal and is therefore straightforward to
translate into Pascal.
: z { x } [: ;] [: ( xt -- n ) execute x 1+ to x x . ;] dup execute ;
You might also want to take a look at
<http://en.wikipedia.org/wiki/Man_or_boy_test>, which also includes
updates to outer locals.
- 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 | 2012-01-03 11:40 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <16udnREZI4kLoJ7SnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #8637 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> [...]
>>: z { x } [: ( xt -- n ) execute x 1+ to x x . ;] ;
>>z constant w
>>:noname ; ['] w ['] w execute
>>
>>Here you have one closure, w (i.e, only one copy of x) and two nested
>>executions.
>>
>>>In what sense is one closure "ordinary" and one not? In something
>>>like pure LISP (or indeed, the lambda calculus) you only have values.
>>
>>It's what languages with closures have done for decades, starting with
>>Scheme and lexically scoped LISPs.
>
> Even earlier, languages with nested procedures such as Algol 60 and
> Pascal behaved this way; they did not have first-class closures, but
> what they had is enough to mix recursion, outer local references, and
> updates.
Well, that's rather different: they didn't have the property of
returning a reference to a context that has exited.
There's a discussion of the way that languages do this in
http://en.wikipedia.org/wiki/Funarg_problem and there is no single
"normal" way that imperative programming languages do it.
> You might also want to take a look at
> <http://en.wikipedia.org/wiki/Man_or_boy_test>, which also includes
> updates to outer locals.
Yuck. "Trying to work it through on paper is probably fruitless..."
What more can I say about COME FROM ? :-)
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-04 15:03 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan4.160302@mips.complang.tuwien.ac.at> |
| In reply to | #8640 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> [...]
>>>: z { x } [: ( xt -- n ) execute x 1+ to x x . ;] ;
>>>z constant w
>>>:noname ; ['] w ['] w execute
>>>
>>>Here you have one closure, w (i.e, only one copy of x) and two nested
>>>executions.
>>>
>>>>In what sense is one closure "ordinary" and one not? In something
>>>>like pure LISP (or indeed, the lambda calculus) you only have values.
>>>
>>>It's what languages with closures have done for decades, starting with
>>>Scheme and lexically scoped LISPs.
>>
>> Even earlier, languages with nested procedures such as Algol 60 and
>> Pascal behaved this way; they did not have first-class closures, but
>> what they had is enough to mix recursion, outer local references, and
>> updates.
>
>Well, that's rather different: they didn't have the property of
>returning a reference to a context that has exited.
Yes, that's the difference between first-class closures and what Algol
60 offered. This difference does not make any difference to the
question of how updates to outer locals should behave, and therefore
no difference for your re-entrancy argument.
>There's a discussion of the way that languages do this in
>http://en.wikipedia.org/wiki/Funarg_problem and there is no single
>"normal" way that imperative programming languages do it.
Do what? And where do I find that on this page?
If you want to deny the significance of Algol 60, Pascal and Scheme in
the development of programming language features, that's fine; I
expect that you still understand what I mean when I write "ordinary
closures".
>> You might also want to take a look at
>> <http://en.wikipedia.org/wiki/Man_or_boy_test>, which also includes
>> updates to outer locals.
>
>Yuck. "Trying to work it through on paper is probably fruitless..."
>What more can I say about COME FROM ? :-)
You can use the same test to test whether the compiler implements your
semantics (and determining the correct result for these semantics on
paper is probably also fruitless), so doesn't this test make your
semantics also a "COME FROM" feature IYO?
Knuth apparently likes to regression-test features by writing
intricate prgrams that use all the features in combination but don't
have any real purpose and whose results are practically impossible to
work out on paper. He also wrote such a test for TeX; that does not
make TeX a "COME FROM" program.
Anyway, the point of my mentioning this test is that people actually
care about the semantics of access to outer locals. Knuth cared
enough to construct a regression test and send a letter to the Algol
Bulletin.
- 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 | 2012-01-04 12:01 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <s6GdnT4sg6t3DpnSnZ2dnUVZ_rqdnZ2d@supernews.com> |
| In reply to | #8654 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> [...]
>>>>: z { x } [: ( xt -- n ) execute x 1+ to x x . ;] ;
>>>>z constant w
>>>>:noname ; ['] w ['] w execute
>>>>
>>>>Here you have one closure, w (i.e, only one copy of x) and two nested
>>>>executions.
>>>>
>>>>>In what sense is one closure "ordinary" and one not? In something
>>>>>like pure LISP (or indeed, the lambda calculus) you only have values.
>>>>
>>>>It's what languages with closures have done for decades, starting with
>>>>Scheme and lexically scoped LISPs.
>>>
>>> Even earlier, languages with nested procedures such as Algol 60 and
>>> Pascal behaved this way; they did not have first-class closures, but
>>> what they had is enough to mix recursion, outer local references, and
>>> updates.
>>
>>Well, that's rather different: they didn't have the property of
>>returning a reference to a context that has exited.
>
> Yes, that's the difference between first-class closures and what Algol
> 60 offered. This difference does not make any difference to the
> question of how updates to outer locals should behave,
> and therefore no difference for your re-entrancy argument.
>>There's a discussion of the way that languages do this in
>>http://en.wikipedia.org/wiki/Funarg_problem and there is no single
>>"normal" way that imperative programming languages do it.
>
> Do what?
Handle nested routines.
> And where do I find that on this page?
"Practical implications"
> If you want to deny the significance of Algol 60, Pascal and Scheme in
> the development of programming language features, that's fine; I
> expect that you still understand what I mean when I write "ordinary
> closures".
I know what you mean by "ordinary closures": you're saying that the
semantics you describe is the norm, and so I need to have a damned
good reason for suggesting anything different. I think I've provided
a damned good reason. Several of them.
I wouldn't deny the significance of Algol 60, Pascal and Scheme in the
development of programming language features. Not everything Algol 60
does turned out to be a good idea. For example, call by name has
gone, and rightly so. People discovered some very nice ways to use
call by name, but it died anyway.
The question is what would be right for Forth. My contention is that
the world has moved on, and Java's approach (that of prohibiting the
capture of mutable locals) is a good way to go in an imperative
language. Java's rule is stronger than I'd propose for Forth, though,
in that it checks the enclosing scope to make sure that values
referenced in a closure are never written to.
>>> You might also want to take a look at
>>> <http://en.wikipedia.org/wiki/Man_or_boy_test>, which also includes
>>> updates to outer locals.
>>
>>Yuck. "Trying to work it through on paper is probably fruitless..."
>>What more can I say about COME FROM ? :-)
>
> You can use the same test to test whether the compiler implements your
> semantics (and determining the correct result for these semantics on
> paper is probably also fruitless), so doesn't this test make your
> semantics also a "COME FROM" feature IYO?
Not quite, because you can't alter a local in an enclosing scope, so
the semantics of this test become much simpler.
> Knuth apparently likes to regression-test features by writing
> intricate prgrams that use all the features in combination but don't
> have any real purpose and whose results are practically impossible to
> work out on paper. He also wrote such a test for TeX; that does not
> make TeX a "COME FROM" program.
Indeed not.
> Anyway, the point of my mentioning this test is that people actually
> care about the semantics of access to outer locals.
Sure, and they also cared about the correct implementation of call by
name. Of course, if you have a feature it's important that it's
implemented correctly.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2012-01-04 21:02 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <je2epe$3h1$1@dont-email.me> |
| In reply to | #8637 |
On 03/01/2012 16:34, Anton Ertl wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Andrew Haley<andrew29@littlepinkcloud.invalid> writes:
> [...]
>> : z { x } [: ( xt -- n ) execute x 1+ to x x . ;] ;
>> z constant w
>> :noname ; ['] w ['] w execute
>>
>> Here you have one closure, w (i.e, only one copy of x) and two nested
>> executions.
>>
>>> In what sense is one closure "ordinary" and one not? In something
>>> like pure LISP (or indeed, the lambda calculus) you only have values.
>>
>> It's what languages with closures have done for decades, starting with
>> Scheme and lexically scoped LISPs.
>
> Even earlier, languages with nested procedures such as Algol 60 and
> Pascal behaved this way; they did not have first-class closures, but
> what they had is enough to mix recursion, outer local references, and
> updates. E.g., the example above can be adapted to use only the
> features available in Pascal and is therefore straightforward to
> translate into Pascal.
>
> : z { x } [: ;] [: ( xt -- n ) execute x 1+ to x x . ;] dup execute ;
>
> You might also want to take a look at
> <http://en.wikipedia.org/wiki/Man_or_boy_test>, which also includes
> updates to outer locals.
>
Out of interest I tried coding the 'man or boy' test using my ANS Forth
implementation of closures.
include xmini_oof.fth
include lambda.fth
:lam func {< n >} [: drop n ;] constant ;lam
1 func one
0 func zero
-1 func -one
defer A
:lam (A) {< k x1 x2 x3 x4 x5 >}
[: {< B >}
k 1- to k
k B x1 x2 x3 x4 A
;]
k 0> if dup exec else drop x4 dup exec x5 dup exec + then
;lam
' (A) is A
10 one -one dup one zero A
cr cr .( Result: ) .
Compare with solutions in other languages at
http://rosettacode.org/wiki/Man_or_boy_test
The above has to be included from a file, typing it in won't work
The result with GForth is:
------------------------
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
include manorboy.fth Loading lambda.fth version 0.3 ...
redefined .error redefined (restore-input) redefined >order redefined
catch
lambda.fth version 0.3 loaded. <0>
Result: -67 ok
------------------------
Apologies for the noisy syntax, in a system integrated properly into a
Forth, (A) would probably be something like:
: (A) { k x1 x2 x3 x4 x5 }
[: { B }
k 1- to k
k B x1 x2 x3 x4 A
;]
k 0> if dup execute else drop x4 dup execute x5 dup execute + then
;
It works with GForth up to k=14, with k=15 it crashes, I suspect the
return stack overflows.
--
Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-05 16:38 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan5.173848@mips.complang.tuwien.ac.at> |
| In reply to | #8663 |
Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>Out of interest I tried coding the 'man or boy' test using my ANS Forth
>implementation of closures.
Cool stuff.
>It works with GForth up to k=14, with k=15 it crashes, I suspect the
>return stack overflows.
You can set the return stack size with the command-line parameter
"-r". E.g.,
gforth -r 1G
gives you a 1GB return stack.
- 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2012-01-07 14:27 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <je9kpb$mv$1@dont-email.me> |
| In reply to | #8682 |
On 05/01/2012 16:38, Anton Ertl wrote: > Gerry Jackson<gerry@jackson9000.fsnet.co.uk> writes: >> Out of interest I tried coding the 'man or boy' test using my ANS Forth >> implementation of closures. > > Cool stuff. > >> It works with GForth up to k=14, with k=15 it crashes, I suspect the >> return stack overflows. > > You can set the return stack size with the command-line parameter > "-r". E.g., > > gforth -r 1G > > gives you a 1GB return stack. Yes, inceasing the return stack and dataspace to 500MB each enabled it to get the correct results for k up to 24 which seems to be the highest k for which a result is published. -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-30 11:33 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2011Dec30.123334@mips.complang.tuwien.ac.at> |
| In reply to | #8372 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> "local" refers to visibility, not lifetime.
>
>Maybe in Lisp. People think different in Forth. Gforth's locals have a
>"funny" visibility when you think it from a Lisp point of view - you can
>declare them anywhere you want, and they stay visible over control flow
>boundaries if it is unambiguous that they are still visible, e.g.
>
>BEGIN { foo } ... UNTIL foo
>
>is legal.
Actually, the visibility of locals in Gforth is based on control flow.
A local is visible at point U if the control flow is guaranteed to
have gone through the definition D of the local (in compiler speak: if
D dominates U).
>From that point of view, quotations have no right to see the
>surrounding locals, because the control flow path that leads to their
>execution is unknown in advance, and therefore it is entirely possible
>that the local already disappeared when the quotation is called (the
>local disappears when the containing word exits or reaches a control
>flow join where the other path does not contain the declaration of this
>local).
No, if we extend the principle above to quotations, we get the
following: Consider a local L with definition D, and a quotation Q
that is defined while L is visible. You had to go through D to get to
the definition of Q, and you have to go through both to get to the
execution of Q, so L is visible during the execution (or it would be,
if we followed this principle, which we don't in this case).
In any case, I don't think that this is very enlightening wrt
the original question.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-30 11:53 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2011Dec30.125340@mips.complang.tuwien.ac.at> |
| In reply to | #8372 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
> therefore it is entirely possible
>that the local already disappeared when the quotation is called (the
>local disappears when the containing word exits
How come?
> or reaches a control
>flow join where the other path does not contain the declaration of this
>local).
If the definition of the quotation is reached through the definition
of the local, the execution is reached through it, too. It does not
matter if the (e.g.) EXECUTE can be reached through a path that does
not contain the definition of a local, because in that case this
EXECUTE cannot execute the quotation.
- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-16 17:18 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2011Dec16.181839@mips.complang.tuwien.ac.at> |
| In reply to | #8113 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>No, it makes far more sense to *copy* the locals. Modifying the
>locals of a word that's not executing is a nightmare scenario.
Implementationwise, it does not complicate things (you need to manage
the storage anyway), but it does rule out optimizations like having
multiple copies of the same (instance of a) local. I also don't think
that using them is a nightmare in general (it's rather like objects),
although I generally use locals as read-only things.
- 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-16 13:16 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <9L2dnaTYBd2TBHbTnZ2dnUVZ_sGdnZ2d@supernews.com> |
| In reply to | #8145 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>No, it makes far more sense to *copy* the locals. Modifying the >>locals of a word that's not executing is a nightmare scenario. > > Implementationwise, it does not complicate things (you need to > manage the storage anyway), but it does rule out optimizations like > having multiple copies of the same (instance of a) local. I also > don't think that using them is a nightmare in general (it's rather > like objects), Well, yes, I take your point, and that seems to be how an object was originally thought of: a block instance that is permitted to outlive its calling statement. However, I don't think that it makes very much sense in this context, and I don't think that it can be done in the general case without a garbage collector, not only for the closures themselves but also for the locals frames of the enclosing words. Eww. :-) > although I generally use locals as read-only things. Indeed, and in recent years the received wisdom about OOP seems to be that immutable objects are to be preferred whenever possible. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-19 15:01 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2011Dec19.160126@mips.complang.tuwien.ac.at> |
| In reply to | #8152 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> I don't think that it can be done in the
>general case without a garbage collector, not only for the closures
>themselves but also for the locals frames of the enclosing words.
I think that you could deal with the locals frames with reference
counting, but since you need garbage collection for the actual
closures, you might as well use it for the locals frames, too.
However, if the closures are explicitly deallocated, as suggested by
Bernd Paysan, reference counting of the locals frames might by a good
idea.
- 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-15 10:40 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <cqidnWQ8IvRmv3fTnZ2dnUVZ_vednZ2d@supernews.com> |
| In reply to | #8093 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Bernd Paysan <bernd.paysan@gmx.de> wrote: >>> 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. > > IMO it's certainly important enough that I will implement it. Whether > it will be important enough that others will implement it, too, will > remain to be seen. I think that quotations without locals are much > better than no quotations, but quotations with locals are better yet. I can see the sense of that. On the other hand, if it's hard to do fewer people will do it. > I also dislike the thought of two desirable features that don't work > together just because of an implementation limitation. Sure, but that's Forth all over. The nice thing about *this* feature, as it stands, is that you get a large linguistic advantage for almost zero cost. I'll have a look at what it takes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-22 16:21 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2011Dec22.172150@mips.complang.tuwien.ac.at> |
| In reply to | #8097 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I also dislike the thought of two desirable features that don't work
>> together just because of an implementation limitation.
>
>Sure, but that's Forth all over.
Bad Forth maybe. While Forth typically does not strive to provide
extremely powerful features at significant implementation cost
(unlike, say, Scheme) and instead tends to go for lower-cost features,
the features it includes tend to work well together. No example comes
to my mind at the moment for two well-respected features in Forth that
do not work together.
>The nice thing about *this* feature,
>as it stands, is that you get a large linguistic advantage for almost
>zero cost.
Yes, neither quotations nor locals in quotations are expensive
to implement.
- 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-22 11:40 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <W7udnbNJ8vQU9m7TnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #8308 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>> I also dislike the thought of two desirable features that don't work >>> together just because of an implementation limitation. >> >>Sure, but that's Forth all over. > > Bad Forth maybe. While Forth typically does not strive to provide > extremely powerful features at significant implementation cost > (unlike, say, Scheme) and instead tends to go for lower-cost > features, the features it includes tend to work well together. True enough. > No example comes to my mind at the moment for two well-respected > features in Forth that do not work together. I accept that point, but locals are hardly well-respected, and Forth tends to concentrate on features that deliver bang for the buck. I suspect that "locals in quotations" may not turn out to be such a feature. YMMV, as usual. >>The nice thing about *this* feature, as it stands, is that you get a >>large linguistic advantage for almost zero cost. > > Yes, neither quotations nor locals in quotations are expensive > to implement. That depends on how locals are implemented, but it may well be so on many systems. I don't know because I haven't investigated in any detail, but I'll post my results once I have. I don't want to mess up a simple few lines of code simply to futz around with locals, but I can live with it if I must. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-26 13:01 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <Gb-dnQQfs47vWWXTnZ2dnUVZ_qqdnZ2d@supernews.com> |
| In reply to | #8311 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>
>>>The nice thing about *this* feature, as it stands, is that you get a
>>>large linguistic advantage for almost zero cost.
>>
>> Yes, neither quotations nor locals in quotations are expensive
>> to implement.
>
> That depends on how locals are implemented, but it may well be so on
> many systems. I don't know because I haven't investigated in any
> detail, but I'll post my results once I have. I don't want to mess up
> a simple few lines of code simply to futz around with locals, but I
> can live with it if I must.
I've come up with a solution that I think is reasonable enough, but
it's a fair bit more complex than the original version that didn't
support LOCALS or RECURSE. You have to save the locals context, clear
it, and then restore it at ;] . It's tolerable, but not the simple
solution that it was without LOCALS or RECURSE . I hope that there
aren't more features that require additional complexity.
Andrew.
\ The size of the compile-time locals structure
lvar-comp cell- @ sizeof constant lvar-size
\ Push and pop the compile-time locals
\ This will leak memory if the compiler aborts
: push-locals ( - a t | 0)
lvar-comp any? dup if
lvar-comp lvar-size allocate throw dup >r lvar-size move
lvar-comp clear r> then ;
: pop-locals ( a t | 0)
if dup lvar-comp lvar-size move free throw then ;
icode (quotation)
here $400 + call
ret end-code
: [: push-locals \ Save our local variables
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>
pop-locals \ Restore our local variables
; immediate
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-12-27 03:54 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <DeidnVVr79pWCGTTnZ2dnUVZ_oudnZ2d@supernews.com> |
| In reply to | #8357 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote:
Ah, I missed a SWAP:
> : push-locals ( - a t | 0)
> lvar-comp any? dup if
> lvar-comp lvar-size allocate throw dup >r lvar-size move
> lvar-comp clear r> then ;
: push-locals ( - a t | 0)
lvar-comp any? dup if
lvar-comp lvar-size allocate throw dup >r lvar-size move
lvar-comp clear r> swap then ;
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2011-12-15 20:11 +0100 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <jcdgpm$o4u$1@online.de> |
| In reply to | #8093 |
Anton Ertl wrote:
> IMO it's certainly important enough that I will implement it.
Anton, you probably have to do nothing. Gforth's local scoping system
already provides starting/ending a scope.
bigForth's locals also have nested scopes; I just had to add postpone
SCOPE/ENDSCOPE to [: and ;] to make it work. Testcase:
: fibonacci { x }
[: { x } x 2 < IF x ELSE x 1- recurse x 2 - recurse + THEN ;]
x swap execute ;
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web