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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-01-01 13:35 -0800 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <cad668d2-1902-4c2e-83b2-f9389e6dcac5@x20g2000yqe.googlegroups.com> |
| In reply to | #8548 |
On Jan 1, 7:22 am, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > There are essentially three ways to implement nested compilation: > 1. compile a jump over the inserted code. > ( I do that in getting not-yet-loaded words from a library) > 2. remember the text and compile it later. > ( That is a trick a use in my class endclass definition) > 3. More elegant is: > compile to a scratch area > once the definition is finished, copy it to its final place. > A direct benefit of 3 is that failed definitions will not enter > the dictionary. Once the mechanism to do 3 is in place, > it should be straightforward to add nesting. > It naturally supports multiple levels of nesting, something I > really don't expect from methods 1 and 2. Since (1) will normally support multi-level nesting from the outset, the question of how straightforward it is to extend it to include multi-level nesting would not airse. (2) and (3) are both "store this now and act on it when the enclosing definition is done", differing in what they store. Support for multi- level nesting would seem to be a similar extension for both.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-02 14:14 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan2.151407@mips.complang.tuwien.ac.at> |
| In reply to | #8548 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>2. remember the text and compile it later.
> ( That is a trick a use in my class endclass definition)
That does not work, not just because of the end-recognition problem
(and yes, "(" is broken for many uses), but also because the context
may change between "now" and "later". The VFX compiler originally
tried to do inlining through text expansion, but that did not work
correctly in all cases.
An example:
variable mycontext
0 mycontext !
: foo mycontext @ postpone literal 1 mycontext +! ; immediate
: bar [: foo . :] foo . ;
bar \ should print 1
execute \ should print 0
(I could also produce an example where stuff like the search order,
BASE, or the content of the current wordlist play a role, but you
might think that the compiler coule work around these problems by
managing this state in some way; for this example it should be obvious
that the compiler cannot do this, because the compiler does not know
that MYCONTEXT is compiler context and how it should be managed.
Instead of storing the text, the compiler could produce an
intermediate representation where all immediate words have been
executed, all names and BASE has been bound, and delay the further
compilation of that intermediate representation to native code.
- 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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-01-03 12:04 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <lx81jg.423@spenarnc.xs4all.nl> |
| In reply to | #8597 |
In article <2012Jan2.151407@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>2. remember the text and compile it later.
>> ( That is a trick a use in my class endclass definition)
>
>That does not work, not just because of the end-recognition problem
>(and yes, "(" is broken for many uses), but also because the context
>may change between "now" and "later". The VFX compiler originally
>tried to do inlining through text expansion, but that did not work
>correctly in all cases.
You are probably right as far as quotations are concerned.
However I use this trick
only in the definition of a class, in a very controlled way.
The text buffers are cleared and reused for the definition of
the next class. So yes, it works.
If you define a class BENCH you get the words
^BENCH and build-BENCH too. This can only be accomplished
by textual manipulation.
I should have realised that this wasn't too relevant in the
current discussion.
<SNIP>
>
>- anton
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-12-31 14:19 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2011Dec31.151928@mips.complang.tuwien.ac.at> |
| In reply to | #8477 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> and of whether the closure holds references to the locals in
>>>enclosing scope or copies of their values, i.e. what the action of TO
>>>on a captured local should be.
>>
>> Why should it hold copies (apart from implementation considerations)?
>
>I think it makes more sense. It doesn't make any sense to have
>multiple "locals" that refer to a single value.
I did not suggest that several locals refer to the same value.
My model is that the execution of a local definition creates an
instance of the local, and no other operation creates user-visible
copies of that instance. Access to that instance is subject to the
usual scoping rules that (I believe) we both agree on.
You seem to prefer introducing additional copies of these instances.
Where would you create them and why?
>In the definition of
>locals, we have the specification "re-entrant and recursive". This
>property only holds if locals do not escape the word in which they're
>defined.
Why do you think so? Can you give an example?
>If you really need a shared value, it's easy to make it a pointer to
>memory.
If you need another instance, it's easy to execute the locals
definition again.
>(As an aside: We've been through this in Javaland during the
>discussion of how lambdas should work, and come to the same
>conclusion. Admittedly the problem is particularly acute because Java
>has threads, and you'd have the problem of a race condition if two
>threads tried to access the same captured local. If we had support
>for threads in standard Forth we'd have the same problem.)
Sure, if you program a race condition, you get a race condition; you
can easily produce a race condition with your shared memory solution,
too.
Since I am not a believer in shared writable memory for inter-thread
communication (at least for high-level programs), I would write my
program such that it uses locals in a read-only way, or that it
creates at least one instance of a written-to local in each thread.
Using the same instance of a local in multiple threads that write to
the local is probably a mistake that the programmer should be made
aware of; I doubt that defining the language to introduce additional
copies is very helpful.
- 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-31 11:46 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <BfqdnfewGq4e12LTnZ2dnUVZ_t2dnZ2d@supernews.com> |
| In reply to | #8516 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>> and of whether the closure holds references to the locals in
>>>>enclosing scope or copies of their values, i.e. what the action of TO
>>>>on a captured local should be.
>>>
>>> Why should it hold copies (apart from implementation considerations)?
>>
>>I think it makes more sense. It doesn't make any sense to have
>>multiple "locals" that refer to a single value.
>
> I did not suggest that several locals refer to the same value.
Surely you did. In something like
: z { x } [: ( - n) x 1+ to x x ;] ;
defer action
z is action
action is not re-entrant.
> You seem to prefer introducing additional copies of these instances.
> Where would you create them and why?
In the closure, to guarantee the properties of locals. The question
is whther a copy of the value or a reference to a local is created.
>>If you really need a shared value, it's easy to make it a pointer to
>>memory.
>
> If you need another instance, it's easy to execute the locals
> definition again.
I don't think it is, as above.
>>(As an aside: We've been through this in Javaland during the
>>discussion of how lambdas should work, and come to the same
>>conclusion. Admittedly the problem is particularly acute because Java
>>has threads, and you'd have the problem of a race condition if two
>>threads tried to access the same captured local. If we had support
>>for threads in standard Forth we'd have the same problem.)
>
> Sure, if you program a race condition, you get a race condition; you
> can easily produce a race condition with your shared memory solution,
> too.
The question is, though, which default behaviour is the more useful.
One can program badly in either. :-)
> Since I am not a believer in shared writable memory for inter-thread
> communication (at least for high-level programs), I would write my
> program such that it uses locals in a read-only way, or that it
> creates at least one instance of a written-to local in each thread.
In which case, as we only care about the values of the locals, it
doesn't much matter.
> Using the same instance of a local in multiple threads that write to
> the local is probably a mistake that the programmer should be made
> aware of; I doubt that defining the language to introduce additional
> copies is very helpful.
Simply forbidding TO would do the job quite nicely.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-02 13:47 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan2.144719@mips.complang.tuwien.ac.at> |
| In reply to | #8518 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>> and of whether the closure holds references to the locals in
>>>>>enclosing scope or copies of their values, i.e. what the action of TO
>>>>>on a captured local should be.
>>>>
>>>> Why should it hold copies (apart from implementation considerations)?
>>>
>>>I think it makes more sense. It doesn't make any sense to have
>>>multiple "locals" that refer to a single value.
>>
>> I did not suggest that several locals refer to the same value.
>
>Surely you did. In something like
>
>: z { x } [: ( - n) x 1+ to x x ;] ;
>
>defer action
>z is action
There's just one local here.
>action is not re-entrant.
Yes, you can write non-re-entrant code with ordinary closures. You
can also write re-entrant code; e.g., what you may have in mind could
be written as:
: z { x } [: ( - n ) x { y } y 1+ to y y ;] ;
or, simpler, just as
: z { x } [: ( - n) x 1+ ;] ;
Why do you think that specifying your variant to be equivalent to the
latter variant "makes more sense"? The ordinary meaning of the
original example creates a counter; you would take that possibility
away.
>> You seem to prefer introducing additional copies of these instances.
>> Where would you create them and why?
>
>In the closure, to guarantee the properties of locals. The question
>is whther a copy of the value or a reference to a local is created.
It's still not clear to me which operation creates the copy. Do you
mean that you create a copy on executing a closure (when you enter the
closure)q?
>>>If you really need a shared value, it's easy to make it a pointer to
>>>memory.
>>
>> If you need another instance, it's easy to execute the locals
>> definition again.
>
>I don't think it is, as above.
In the example above it's easy to do what you seem to want to do even
in the presence of ordinary closures. It's also simple to create
another instance:
defer action2
z is action2
defer action3
z is action3
gives you another two instances.
>> Sure, if you program a race condition, you get a race condition; you
>> can easily produce a race condition with your shared memory solution,
>> too.
>
>The question is, though, which default behaviour is the more useful.
>One can program badly in either. :-)
One can create stateful objects, e.g., counters, with ordinary
closures, but apparently not with your model. Conversely, one can do
everything you can do with your copying model with ordinary closures
by inserting explicit copies in the appropriate places. So it seems
to me that the ordinary behaviour is more useful (ok, some people
dispute the usefulness of stateful objects, but they would not use TO
anyway, so for them there is no difference between the behaviours).
>Simply forbidding TO would do the job quite nicely.
Sure, if we do that, there is no difference between the two models.
It's probably a good idea to follow the discipline of not using TO in
most of the code. However, given that you can do some interesting
things with ordinary closures and TO, I certainly argue that this
model is more useful (even if this feature would only be used in
defining some libraries).
- 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-02 10:19 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <YZmdnSKlN8yJRJzSnZ2dnUVZ_qWdnZ2d@supernews.com> |
| In reply to | #8596 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>> and of whether the closure holds references to the locals in
>>>>>>enclosing scope or copies of their values, i.e. what the action of TO
>>>>>>on a captured local should be.
>>>>>
>>>>> Why should it hold copies (apart from implementation considerations)?
>>>>
>>>>I think it makes more sense. It doesn't make any sense to have
>>>>multiple "locals" that refer to a single value.
>>>
>>> I did not suggest that several locals refer to the same value.
>>
>>Surely you did. In something like
>>
>>: z { x } [: ( - n) x 1+ to x x ;] ;
>>
>>defer action
>>z is action
>
> There's just one local here.
No. There may be many active instances of z, and all of their
instances of x refer to the same value.
>>action is not re-entrant.
>
> Yes, you can write non-re-entrant code with ordinary closures.
Only if your closures capture references to locals rather than the
values of the locals.
> Why do you think that specifying your variant to be equivalent to the
> latter variant "makes more sense"? The ordinary meaning of the
> original example creates a counter; you would take that possibility
> away.
Because a basic guarantee of locals is that they are re-entrant. This
is such a fundamental property that it is more important than other
considerations, IMO.
>>> You seem to prefer introducing additional copies of these instances.
>>> Where would you create them and why?
>>
>>In the closure, to guarantee the properties of locals. The question
>>is whther a copy of the value or a reference to a local is created.
>
> It's still not clear to me which operation creates the copy. Do you
> mean that you create a copy on executing a closure (when you enter the
> closure)q?
You have to either create a bunch of references to the enclosing local
frame or a bunch of copies of the values. You have to do that when
the closure is created, whether copying the values or creating some
references to them.
>>> Sure, if you program a race condition, you get a race condition; you
>>> can easily produce a race condition with your shared memory solution,
>>> too.
>>
>>The question is, though, which default behaviour is the more useful.
>>One can program badly in either. :-)
>
> One can create stateful objects, e.g., counters, with ordinary
> closures, but apparently not with your model. Conversely, one can
> do everything you can do with your copying model with ordinary
> closures by inserting explicit copies in the appropriate places.
Exactly.
> So it seems to me that the ordinary behaviour is more useful (ok,
> some people dispute the usefulness of stateful objects, but they
> would not use TO anyway, so for them there is no difference between
> the behaviours).
In what sense is one closure "ordinary" and one not? In something
like pure LISP (or indeed, the lambda calculus) you only have values.
That's my mental model: the captured locals are a snapshot of the
values when the closure was created.
>>Simply forbidding TO would do the job quite nicely.
>
> Sure, if we do that, there is no difference between the two models.
>
> It's probably a good idea to follow the discipline of not using TO in
> most of the code. However, given that you can do some interesting
> things with ordinary closures and TO, I certainly argue that this
> model is more useful (even if this feature would only be used in
> defining some libraries).
OK. I doubt its usefulness very much; it's about as useful as a COME
FROM statement IMO, i.e. any use of it is more likely to make a
program worse than better. For example, a word might be executing
while some other word in some other thread is fiddling with its
locals. It becomes impossible to reason about locals once a closure
has been created because they are no longer local. And, of course,
one response is "Don't do that, then" but the question is whether an
extension is likely to promote understandable and reliable programs or
not.
But, as ever, YMMV.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-03 09:08 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan3.100839@mips.complang.tuwien.ac.at> |
| In reply to | #8601 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>> and of whether the closure holds references to the locals in
>>>>>>>enclosing scope or copies of their values, i.e. what the action of TO
>>>>>>>on a captured local should be.
>>>>>>
>>>>>> Why should it hold copies (apart from implementation considerations)?
>>>>>
>>>>>I think it makes more sense. It doesn't make any sense to have
>>>>>multiple "locals" that refer to a single value.
>>>>
>>>> I did not suggest that several locals refer to the same value.
>>>
>>>Surely you did. In something like
>>>
>>>: z { x } [: ( - n) x 1+ to x x ;] ;
>>>
>>>defer action
>>>z is action
>>
>> There's just one local here.
>
>No. There may be many active instances of z, and all of their
>instances of x refer to the same value.
In this example, there is only one local: X. And it is instantiated
only once (because Z is only called once), and it created one closure
(stored in ACTION). And that closure is not invoked at all.
I don't know what you mean with "active instances" (closure
executions?), but whatever it is, there is certainly not more than one
of them in this example.
>> It's still not clear to me which operation creates the copy. Do you
>> mean that you create a copy on executing a closure (when you enter the
>> closure)q?
>
>You have to either create a bunch of references to the enclosing local
>frame or a bunch of copies of the values. You have to do that when
>the closure is created, whether copying the values or creating some
>references to them.
So you would do the copies on closure creation. That does not give
you the re-entrancy guarantee you desire, because the same closure
would refer to the same copy of the local, and the closure can be
executed several times, possibly at the same time:
: 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.
Also, looking at Wikipedia, it describes closures to have state
<http://en.wikipedia.org/wiki/Closure_(computer_science)#State_representation>.
It also mentions concurrent programming in <http://en.wikipedia.org/wiki/Closure_(computer_science)#Implementation_and_theory>:
|An important issue for closures in concurrent programming languages is
|whether the variables in a closure can be updated and, if so, how
|these updates can be synchronized.
>It becomes impossible to reason about locals once a closure
>has been created because they are no longer local.
It is entirely possible to reason about locals once a closure has been
created. In particular:
For a given local, if there is no TO to that local in a closure that
captures that local, there cannot be a race condition involving that
local.
Since the scope of locals is very limited, you only need to look at
one definition to make use of that rule. And if you program such that
that rule applies to every local, you can still do everything that you
can do with your implicitly-copying locals.
For stateful closures, you can reason about them just like you can
reason about stateful objects; it's actually probably easier, because
the scope of locals is more limited than the scope of instance
variables in most object-oriented languages (there are no "public"
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 04:47 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <ksKdnUkYeokpQZ_SnZ2dnUVZ_qednZ2d@supernews.com> |
| In reply to | #8621 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>>> and of whether the closure holds references to the locals in
>>>>>>>>enclosing scope or copies of their values, i.e. what the action of TO
>>>>>>>>on a captured local should be.
>>>>>>>
>>>>>>> Why should it hold copies (apart from implementation considerations)?
>>>>>>
>>>>>>I think it makes more sense. It doesn't make any sense to have
>>>>>>multiple "locals" that refer to a single value.
>>>>>
>>>>> I did not suggest that several locals refer to the same value.
>>>>
>>>>Surely you did. In something like
>>>>
>>>>: z { x } [: ( - n) x 1+ to x x ;] ;
>>>>
>>>>defer action
>>>>z is action
>>>
>>> There's just one local here.
>>
>>No. There may be many active instances of z, and all of their
>>instances of x refer to the same value.
>
> In this example, there is only one local: X. And it is instantiated
> only once (because Z is only called once), and it created one closure
> (stored in ACTION). And that closure is not invoked at all.
It is invoked by code not shown here.
>>You have to either create a bunch of references to the enclosing local
>>frame or a bunch of copies of the values. You have to do that when
>>the closure is created, whether copying the values or creating some
>>references to them.
>
> So you would do the copies on closure creation. That does not give
> you the re-entrancy guarantee you desire, because the same closure
> would refer to the same copy of the local, and the closure can be
> executed several times, possibly at the same time:
That's a fair point. It depends on whether the closure contains
read-only values that are used to initialize locals when the closure
executes. I would have thought it makes more sense to do that than
for TO to overwrite values in the closure itself. However, even if
you do allow TO to overwrite values in the closure, at least you don't
have the property of modifying the locals in the scope of the creator.
> It also mentions concurrent programming in <http://en.wikipedia.org/wiki/Closure_(computer_science)#Implementation_and_theory>:
>
> |An important issue for closures in concurrent programming languages is
> |whether the variables in a closure can be updated and, if so, how
> |these updates can be synchronized.
That's true: it's up for debate whether a closure should contain
writable values or not. And, IMO, one very sensible response is
"Don't do that."
>>It becomes impossible to reason about locals once a closure
>>has been created because they are no longer local.
>
> It is entirely possible to reason about locals once a closure has been
> created. In particular:
>
> For a given local, if there is no TO to that local in a closure that
> captures that local, there cannot be a race condition involving that
> local.
Indeed, that solves the problem. But why have the problem in the
first place?
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-03 16:55 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan3.175525@mips.complang.tuwien.ac.at> |
| In reply to | #8623 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>: z { x } [: ( - n) x 1+ to x x ;] ;
>>>>>
>>>>>defer action
>>>>>z is action
>>>>
>>>> There's just one local here.
>>>
>>>No. There may be many active instances of z, and all of their
>>>instances of x refer to the same value.
>>
>> In this example, there is only one local: X. And it is instantiated
>> only once (because Z is only called once), and it created one closure
>> (stored in ACTION). And that closure is not invoked at all.
>
>It is invoked by code not shown here.
Do you really want to lead a discussion where you make concrete claims
about a concrete example, but your claims are based on stuff that is
not there? I certainly don't take someone seriously who engages in
such practices.
>That's a fair point. It depends on whether the closure contains
>read-only values that are used to initialize locals when the closure
>executes. I would have thought it makes more sense to do that than
>for TO to overwrite values in the closure itself. However, even if
>you do allow TO to overwrite values in the closure, at least you don't
>have the property of modifying the locals in the scope of the creator.
So you have eliminated the possibility for several closures to use a
shared outer variable to communicate, but each closure is not
re-entrant. That's the worst of all worlds IMO, definitely not a win.
>Indeed, that solves the problem. But why have the problem in the
>first place?
If you don't want to make use of that feature, then don't. Others
have found interesting uses for the feature, so I wouldn't design that
feature out just because you don't want to use it.
- 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:28 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <GOidnd8FLcIlp57SnZ2dnUVZ_hOdnZ2d@supernews.com> |
| In reply to | #8638 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>>>: z { x } [: ( - n) x 1+ to x x ;] ;
>>>>>>
>>>>>>defer action
>>>>>>z is action
>>>>>
>>>>> There's just one local here.
>>>>
>>>>No. There may be many active instances of z, and all of their
>>>>instances of x refer to the same value.
>>>
>>> In this example, there is only one local: X. And it is instantiated
>>> only once (because Z is only called once), and it created one closure
>>> (stored in ACTION). And that closure is not invoked at all.
>>
>>It is invoked by code not shown here.
>
> Do you really want to lead a discussion where you make concrete
> claims about a concrete example, but your claims are based on stuff
> that is not there?
I don't have any way of showing how a word may be executed in another
thread or in an interrupt: there is no standard way to do it. There's
nothing I can do about that, but it is the crux of the re-entrancy
question.
>>That's a fair point. It depends on whether the closure contains
>>read-only values that are used to initialize locals when the closure
>>executes. I would have thought it makes more sense to do that than
>>for TO to overwrite values in the closure itself. However, even if
>>you do allow TO to overwrite values in the closure, at least you don't
>>have the property of modifying the locals in the scope of the creator.
>
> So you have eliminated the possibility for several closures to use a
> shared outer variable to communicate, but each closure is not
> re-entrant. That's the worst of all worlds IMO, definitely not a
> win.
Indeed, that does not meet the spec of re-entrancy. The closure must
contain immutable copies of the values.
>>Indeed, that solves the problem. But why have the problem in the
>>first place?
>
> If you don't want to make use of that feature, then don't. Others
> have found interesting uses for the feature, so I wouldn't design that
> feature out just because you don't want to use it.
The question was that of the best choice, and that's a matter of
judgment. I think it doesn't make much sense to have a "halt and
catch fire" feature and then say "Don't use it, then." The ability to
modify the locals of another word while it executes is, IMO, such a
feature. It is, as I said, rather like COME FROM (or indeed arbitrary
return stack manipulation): you can think of ways to use it but, on
the whole, you're better off without it.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-04 14:52 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan4.155227@mips.complang.tuwien.ac.at> |
| In reply to | #8639 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Do you really want to lead a discussion where you make concrete
>> claims about a concrete example, but your claims are based on stuff
>> that is not there?
>
>I don't have any way of showing how a word may be executed in another
>thread or in an interrupt: there is no standard way to do it.
So what. Neither quotations nor closures are standardized (and
closures are not even implemented), that has not stopped us from
showing examples and discussing how they should work.
>>>Indeed, that solves the problem. But why have the problem in the
>>>first place?
>>
>> If you don't want to make use of that feature, then don't. Others
>> have found interesting uses for the feature, so I wouldn't design that
>> feature out just because you don't want to use it.
>
>The question was that of the best choice, and that's a matter of
>judgment. I think it doesn't make much sense to have a "halt and
>catch fire" feature and then say "Don't use it, then." The ability to
>modify the locals of another word while it executes is, IMO, such a
>feature.
IMO it isn't. There are ways to use this feature well. E.g., you can
implement stateful objects with it. So if this feature is a
"halt-and-catch-fire" feature, so are stateful objects. While some
functional programming fanatics might agree with that, many
programmers will disagree.
- 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 09:54 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <PMCdna_dgf3X65nSnZ2dnUVZ_h2dnZ2d@supernews.com> |
| In reply to | #8651 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >>>>Indeed, that solves the problem. But why have the problem in the >>>>first place? >>> >>> If you don't want to make use of that feature, then don't. Others >>> have found interesting uses for the feature, so I wouldn't design that >>> feature out just because you don't want to use it. >> >>The question was that of the best choice, and that's a matter of >>judgment. I think it doesn't make much sense to have a "halt and >>catch fire" feature and then say "Don't use it, then." The ability to >>modify the locals of another word while it executes is, IMO, such a >>feature. > > IMO it isn't. There are ways to use this feature well. E.g., you > can implement stateful objects with it. So if this feature is a > "halt-and-catch-fire" feature, so are stateful objects. That doeesn't really follow. cf: you can implement a sort with COME FROM. So, if COME FROM is a "halt-and-catch-fire" feature, so is a sort. Also, just because Feature X can be used to create stateful objects, which are undeniably useful, it doesn't imply that Feature X is itself useful, because there may be better ways to create stateful objects. > While some functional programming fanatics might agree with that, > many programmers will disagree. Probably. This is still a controversial area. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-04 17:28 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan4.182820@mips.complang.tuwien.ac.at> |
| In reply to | #8652 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>That doeesn't really follow. cf: you can implement a sort with COME
>FROM. So, if COME FROM is a "halt-and-catch-fire" feature, so is a
>sort.
Congratulations, you proved that "COME FROM" is not a
"halt-and-catch-fire" feature (at least if you can indeed implement a
sort with it).
>Also, just because Feature X can be used to create stateful objects,
>which are undeniably useful, it doesn't imply that Feature X is itself
>useful, because there may be better ways to create stateful objects.
Yes, a feature may be used to create another, useful feature, and may
be worse in cost/benefit than the other feature, in particular if it
does not offer anything extra. But I have seen cool uses of ordinary
closures, including stateful closures, and these uses included things
other than stateful objects, so I am convinced that this feature is
useful.
- 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:10 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <boGdneQNxYGFC5nSnZ2dnUVZ_rmdnZ2d@supernews.com> |
| In reply to | #8657 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>That doeesn't really follow. cf: you can implement a sort with COME >>FROM. So, if COME FROM is a "halt-and-catch-fire" feature, so is a >>sort. > > Congratulations, you proved that "COME FROM" is not a > "halt-and-catch-fire" feature (at least if you can indeed implement a > sort with it). Not really, no. Just because the bomb doesn't go off every time... >>Also, just because Feature X can be used to create stateful objects, >>which are undeniably useful, it doesn't imply that Feature X is itself >>useful, because there may be better ways to create stateful objects. > > Yes, a feature may be used to create another, useful feature, and > may be worse in cost/benefit than the other feature, in particular > if it does not offer anything extra. But I have seen cool uses of > ordinary closures, including stateful closures, and these uses > included things other than stateful objects, so I am convinced that > this feature is useful. That sounds to me like a far more fruitful discussion. "Closures that capture mutable locals are better than those that don't because you can do X" ... Andrew.
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-01-03 10:09 -0800 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <4bce7d52-b2e8-41db-bb42-6397d9b8ae64@24g2000yqi.googlegroups.com> |
| In reply to | #8638 |
On Jan 3, 11:55 am, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > So you have eliminated the possibility for several closures to use a > shared outer variable to communicate, but each closure is not > re-entrant. That's the worst of all worlds IMO, definitely not a win. But if its a step toward re-entrancy, even at the cost of not being able to use an outer variable to communicate, it might be a step toward a win. If its something that can be peeled off and handed to task to chew on, its ok if the task spits the result back in pipe. Or peels off its own result and hands that back before freeing its input closure and closing.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-04 17:14 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan4.181441@mips.complang.tuwien.ac.at> |
| In reply to | #8643 |
BruceMcF <agila61@netscape.net> writes:
>On Jan 3, 11:55=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>
>> So you have eliminated the possibility for several closures to use a
>> shared outer variable to communicate, but each closure is not
>> re-entrant. =A0That's the worst of all worlds IMO, definitely not a win.
>
>But if its a step toward re-entrancy, even at the cost of not being
>able to use an outer variable to communicate, it might be a step
>toward a win.
It's definitely a loss. Re-entrancy is easy with ordinary closures,
so Amdrew's closures are not a step towards re-entrancy.
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., "!".
- 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 11:26 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <9JSdnR-85ZFAFpnSnZ2dnUVZ_qmdnZ2d@supernews.com> |
| In reply to | #8655 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > 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., "!". True, but re-entrancy is a requirement for locals. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-01-04 17:49 +0000 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <2012Jan4.184947@mips.complang.tuwien.ac.at> |
| In reply to | #8656 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>True, but re-entrancy is a requirement for locals.
It may be your requirement for locals, but the designers of Algol 60,
Pascal, and Scheme obviously did not have that requirement, and
neither do I.
- 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:11 -0600 |
| Subject | Re: Quotations [Was: return address manipulation] |
| Message-ID | <boGdnecNxYH9C5nSnZ2dnUVZ_rmdnZ2d@supernews.com> |
| In reply to | #8658 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Andrew Haley <andrew29@littlepinkcloud.invalid> writes: >>True, but re-entrancy is a requirement for locals. > > It may be your requirement for locals, but the designers of Algol 60, > Pascal, and Scheme obviously did not have that requirement, and > neither do I. Sorry, I wasn't clear enough about what I meant: re-entrancy is a requirement for Forth's locals. Andrew.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.forth
csiph-web