Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #13572 > unrolled thread
| Started by | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| First post | 2012-07-04 23:21 +0200 |
| Last post | 2012-07-14 21:25 -0700 |
| Articles | 20 on this page of 244 — 18 participants |
Back to article view | Back to comp.lang.forth
RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-04 23:21 +0200
Re: RfD: Make ENVIRONMENT? obsolescent "A. K." <akk@nospam.org> - 2012-07-04 23:51 +0200
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-04 16:53 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-05 11:17 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-05 15:21 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-05 16:09 +0000
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-05 10:41 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-06 01:13 +0200
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-05 21:06 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-06 14:44 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-07 00:31 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-07 08:52 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-07 19:03 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-09 14:54 +0000
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-07 22:45 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-08 01:19 +0200
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-07 20:01 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-09 17:08 +0000
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-09 11:48 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-09 15:54 +0000
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-09 11:57 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-09 15:35 +0000
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-09 16:32 +0000
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-10 14:02 +0000
Re: RfD: Make ENVIRONMENT? obsolescent "Elizabeth D. Rather" <erather@forth.com> - 2012-07-10 15:41 -1000
Re: RfD: Make ENVIRONMENT? obsolescent "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-11 03:28 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-11 04:15 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-12 22:18 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-11 14:11 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-11 11:53 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-12 14:00 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-12 12:21 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 14:35 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 11:55 -0500
Re: RfD: Make ENVIRONMENT? obsolescent "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-11 03:26 -0400
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-11 16:29 +0000
Re: RfD: Make ENVIRONMENT? obsolescent "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-12 05:17 -0400
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-12 15:17 +0000
Re: RfD: Make ENVIRONMENT? obsolescent "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-13 03:31 -0400
Re: RfD: Make ENVIRONMENT? obsolescent "Elizabeth D. Rather" <erather@forth.com> - 2012-07-12 21:41 -1000
Re: RfD: Make ENVIRONMENT? obsolescent "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-13 04:10 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 04:21 -0500
OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-13 07:46 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-13 04:53 -0700
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-13 08:16 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 09:27 -0500
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] BruceMcF <agila61@netscape.net> - 2012-07-13 07:51 -0700
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-14 03:25 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-14 13:25 +0000
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-15 07:09 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-15 12:04 -0500
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-16 06:41 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-16 07:06 -0500
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-16 16:33 +0000
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] BruceMcF <agila61@netscape.net> - 2012-07-16 10:38 -0700
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] BruceMcF <agila61@netscape.net> - 2012-07-14 15:29 -0700
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-15 07:59 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Elizabeth D. Rather" <erather@forth.com> - 2012-07-15 08:24 -1000
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] BruceMcF <agila61@netscape.net> - 2012-07-15 12:04 -0700
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-16 07:20 -0400
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] "Elizabeth D. Rather" <erather@forth.com> - 2012-07-16 07:46 -1000
Re: OT: ANS' EVALUATE, was [Re: RfD: Make ENVIRONMENT? obsolescent] BruceMcF <agila61@netscape.net> - 2012-07-16 10:57 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 04:18 -0500
Re: RfD: Make ENVIRONMENT? obsolescent "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-07-13 07:45 -0400
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 16:34 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Paul Rubin <no.email@nospam.invalid> - 2012-07-13 12:57 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Josh Grams <josh@qualdan.com> - 2012-07-07 10:45 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-07 19:07 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-09 15:11 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-08 02:15 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-09 08:36 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-09 13:16 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-10 07:20 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-10 04:19 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-10 10:19 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-10 10:18 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-10 15:38 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-10 12:06 -0500
Re: RfD: Make ENVIRONMENT? obsolescent "Elizabeth D. Rather" <erather@forth.com> - 2012-07-10 08:21 -1000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-10 16:17 -0500
Re: RfD: Make ENVIRONMENT? obsolescent "Elizabeth D. Rather" <erather@forth.com> - 2012-07-10 11:58 -1000
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-11 13:32 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-11 10:37 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-11 16:44 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-11 12:53 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-12 14:23 +0000
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-12 15:45 +0000
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 14:15 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 09:58 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-12 12:40 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 15:23 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 12:18 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-12 09:09 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-12 12:52 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-13 08:02 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 12:30 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-13 12:15 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-14 03:39 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-14 16:47 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-15 03:19 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-15 12:41 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-16 04:02 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-16 16:07 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-17 03:52 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-19 20:00 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-20 04:09 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-20 12:27 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 15:55 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 12:37 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-13 12:16 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-14 03:52 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-11 02:38 +0200
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-11 06:39 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-11 02:06 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-11 04:21 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-11 02:39 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-11 04:20 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Josh Grams <josh@qualdan.com> - 2012-07-11 20:24 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-12 01:53 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-12 23:38 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 05:29 -0500
Re: RfD: Make ENVIRONMENT? obsolescent "Elizabeth D. Rather" <erather@forth.com> - 2012-07-13 08:27 -1000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-13 22:45 +0200
Re: RfD: Make ENVIRONMENT? obsolescent "Elizabeth D. Rather" <erather@forth.com> - 2012-07-13 11:11 -1000
Re: RfD: Make ENVIRONMENT? obsolescent Josh Grams <josh@qualdan.com> - 2012-07-13 02:20 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-12 01:33 -0700
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-12 09:43 +0000
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-12 16:08 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Josh Grams <josh@qualdan.com> - 2012-07-13 03:12 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 05:37 -0500
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-11 16:23 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-12 23:36 +0200
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-13 08:16 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 05:38 -0500
Re: RfD: Make ENVIRONMENT? obsolescent stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-13 11:36 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 09:37 -0500
partitioning words (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 16:41 +0000
Re: partitioning words (was: RfD: Make ENVIRONMENT? obsolescent) Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-13 22:31 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-13 22:03 +0200
C interface (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-14 12:55 +0000
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-14 20:45 +0200
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-16 14:34 +0000
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-16 15:24 +0000
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-16 23:18 +0200
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-17 11:33 +0000
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-17 12:05 +0000
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-17 19:08 +0200
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-17 19:14 +0200
time_t Re: C interface Aleksej Saushev <asau@inbox.ru> - 2012-07-20 01:15 +0400
Re: time_t Re: C interface anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-20 15:12 +0000
Re: time_t Re: C interface stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-20 16:04 +0000
Re: time_t Re: C interface Spam@ControlQ.com - 2012-07-20 12:20 -0400
Re: time_t Re: C interface "Elizabeth D. Rather" <erather@forth.com> - 2012-07-20 08:12 -1000
Re: time_t Re: C interface anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-23 15:32 +0000
Re: time_t Re: C interface Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-20 20:22 +0200
Re: time_t Re: C interface Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-20 20:21 +0200
Re: time_t Re: C interface stephenXXX@mpeforth.com (Stephen Pelc) - 2012-07-20 19:00 +0000
Re: time_t Re: C interface Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-21 00:21 +0200
Re: time_t Re: C interface Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-21 10:37 +0000
Re: time_t Re: C interface BruceMcF <agila61@netscape.net> - 2012-07-21 15:22 -0700
Re: time_t Re: C interface anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-23 16:23 +0000
Re: time_t Re: C interface BruceMcF <agila61@netscape.net> - 2012-07-20 14:35 -0700
Re: time_t Re: C interface anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-23 15:24 +0000
Re: time_t Re: C interface Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-23 11:03 -0500
Re: time_t Re: C interface Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-23 11:17 -0500
Re: time_t Re: C interface anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-23 17:12 +0000
Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-19 17:10 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-20 11:15 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-20 20:18 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-20 16:27 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-21 00:21 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-20 19:49 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-21 15:42 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-23 21:02 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-23 21:31 -0400
Re: RfD: Make ENVIRONMENT? obsolescent mhx@iae.nl - 2012-07-21 01:18 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-21 11:59 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-21 14:43 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-21 19:36 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-21 21:41 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-22 14:13 +0000
Re: RfD: Make ENVIRONMENT? obsolescent mhx@iae.nl (Marcel Hendrix) - 2012-07-22 09:11 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-23 15:34 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-23 20:05 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-25 12:52 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-25 23:21 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-26 14:16 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-27 23:18 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Paul Rubin <no.email@nospam.invalid> - 2012-07-27 16:13 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-28 08:21 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-29 01:07 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-29 07:47 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-30 00:50 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-23 21:10 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-24 13:38 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-25 13:58 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-25 23:22 +0200
objects (was: RfD: Make ENVIRONMENT? obsolescent) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-26 14:49 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-26 04:30 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-26 04:48 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-27 23:31 +0200
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-30 04:40 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-21 10:57 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-23 21:20 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Doug Hoffman <glidedog@gmail.com> - 2012-07-20 11:21 -0400
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-20 19:48 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-11 14:04 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Alex McDonald <blog@rivadpm.com> - 2012-07-11 09:04 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-12 02:59 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-12 22:58 +0200
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-12 22:06 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-13 05:44 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-14 16:10 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-15 03:26 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-16 11:13 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-17 04:02 -0500
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-17 12:35 +0000
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 16:14 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-13 20:13 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-14 13:09 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-14 20:19 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-06 17:07 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-06 20:20 +0200
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-11 17:23 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-08-12 03:33 +0200
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-12 11:02 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-13 02:20 +0000
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-12 20:34 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-13 16:31 +0000
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-15 13:07 -0700
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-10 07:24 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Mark Wills <markrobertwills@yahoo.co.uk> - 2012-07-10 08:06 -0700
Re: RfD: Make ENVIRONMENT? obsolescent Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-07-10 10:20 -0500
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-10 15:26 -0700
Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-14 21:10 -0700
Re: RfD: Make ENVIRONMENT? obsolescent anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-07-09 14:24 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Josh Grams <josh@qualdan.com> - 2012-07-10 01:27 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-07 11:34 +0000
Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-05 23:37 +0000
WANT revisited Re: RfD: Make ENVIRONMENT? obsolescent Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-07-10 15:11 +0000
Re: WANT revisited Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-10 17:59 -0700
Re: WANT revisited Re: RfD: Make ENVIRONMENT? obsolescent Bernd Paysan <bernd.paysan@gmx.de> - 2012-07-12 23:45 +0200
Re: WANT revisited Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-12 21:44 -0700
Re: WANT revisited Re: RfD: Make ENVIRONMENT? obsolescent BruceMcF <agila61@netscape.net> - 2012-07-14 21:25 -0700
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-07-23 16:23 +0000 |
| Subject | Re: time_t Re: C interface |
| Message-ID | <2012Jul23.182353@mips.complang.tuwien.ac.at> |
| In reply to | #14239 |
Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>In article <juc7is$6ul$2@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote:
>Defining a time_t is a reasonable portability solution within C.
>Accepting time_t from C leads to considerable difficulties
>especially for 16 bit systems.
Do you really think that we will use a standardized C interface on
16-bit systems?
It actually seems to me that even now Forth programs for 16-bit
platforms are written for a particular Forth system, not for standard
Forth, so worrying about portability to 16-bit platforms is almost as
pointless as worrying about portability to 1s-complement signed
integers.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | BruceMcF <agila61@netscape.net> |
|---|---|
| Date | 2012-07-20 14:35 -0700 |
| Subject | Re: time_t Re: C interface |
| Message-ID | <1c26b95e-2641-4f79-b7d7-365163f186eb@googlegroups.com> |
| In reply to | #14214 |
On Friday, July 20, 2012 12:04:42 PM UTC-4, Stephen Pelc wrote: > If you define time_t as a Forth double integer, > then some form of artifice is required on a 64 bit > Forth system. In what sense? That implementation specific code somewhere has done an S>D or (if unsigned) "0" somewhere to compatible with the specified return type?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-07-23 15:24 +0000 |
| Subject | Re: time_t Re: C interface |
| Message-ID | <2012Jul23.172427@mips.complang.tuwien.ac.at> |
| In reply to | #14214 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Fri, 20 Jul 2012 15:12:34 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>>Even on 32-bit hardware, I guess. That's interesting. Thank you. So
>>we really should map time_t to d. Any objections to that?
>
>Not really, but it raises the reality that among Unices, these types
>can vary, as well as among Forths.
>
>If you define time_t as a Forth double integer, then some form of
>artifice is required on a 64 bit Forth system.
What do you mean by that?
> I'm not arguing,
>just pointing out that portability of C and portability of Forth
>can raise conflicting issues when we mix the languages.
What conflicting issues?
In a later posting you wrote that VFX's C interface supports
converting between C and Forth types. That's all that's needed, plus
a consensus on which C types are mapped to which Forth types. Do you
have something else in mind?
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-07-23 11:03 -0500 |
| Subject | Re: time_t Re: C interface |
| Message-ID | <LZOdnRObj7x06JDNnZ2dnUVZ8hudnZ2d@supernews.com> |
| In reply to | #14314 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > VFX's C interface supports converting between C and Forth types. > That's all that's needed, plus a consensus on which C types are > mapped to which Forth types. Please forgive me if I'm misinterpreting you, but we don't know what C type a time_t is. All we know for certain is that it is an arithmetic type. 16-bit Forth systems exist; so do 64-bit time_t's. How can there be a consensus on mapping a 64-bit time_t onto a Forth type? I suppose we know that no 16-bit system has a 16-bit time_t, and that time_t must be an integer type, so it has to be a Forth double. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-07-23 11:17 -0500 |
| Subject | Re: time_t Re: C interface |
| Message-ID | <LKSdnQ6Ka4eI5JDNnZ2dnUVZ8rydnZ2d@supernews.com> |
| In reply to | #14316 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > >> VFX's C interface supports converting between C and Forth types. >> That's all that's needed, plus a consensus on which C types are >> mapped to which Forth types. > > Please forgive me if I'm misinterpreting you, but we don't know what C > type a time_t is. All we know for certain is that it is an arithmetic > type. 16-bit Forth systems exist; so do 64-bit time_t's. How can > there be a consensus on mapping a 64-bit time_t onto a Forth type? I > suppose we know that no 16-bit system has a 16-bit time_t, Agh. No 16-bit system has a 64-bit time_t, > and that time_t must be an integer type, so it has to be a Forth > double. > > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-07-23 17:12 +0000 |
| Subject | Re: time_t Re: C interface |
| Message-ID | <2012Jul23.191207@mips.complang.tuwien.ac.at> |
| In reply to | #14316 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Please forgive me if I'm misinterpreting you, but we don't know what C
>type a time_t is. All we know for certain is that it is an arithmetic
>type. 16-bit Forth systems exist; so do 64-bit time_t's. How can
>there be a consensus on mapping a 64-bit time_t onto a Forth type? I
>suppose we know that no 16-bit system has a 16-bit time_t, and that
>time_t must be an integer type, so it has to be a Forth double.
Yes, in this case a d is certainly enough, because on every C platform
a time_t fits into a d (as you point out later).
In general, we have to look at the concrete type and think about if n
will be enough on all realistic platforms, and if not, use d. As
mentioned elsewhere, I don't consider a 16-bit Forth system that runs
standard Forth programs that call C libraries a realistic platform.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-07-19 17:10 +0000 |
| Subject | Re: C interface (was: RfD: Make ENVIRONMENT? obsolescent) |
| Message-ID | <2012Jul19.191047@mips.complang.tuwien.ac.at> |
| In reply to | #14120 |
Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Well, by 2038 hopefully all Forth systems that call C functions will
>> be 64-bit or higher, so having "n" for time_t should be viable.
>
>32 bit processors have been around since the 80s, yet we still have 8
>bit processors and Forths supporting them. So by 2038, which is only 26
>years ahead, 32 bit processors will still exist, especially in the field
>where Forth is used quite often: embedded devices. And these embedded
>devices in the 32 bit class have C libraries you might want to call.
And you count on time_t being 64-bit there? They did not do it for
off_t (or only if you ask for it).
But ok, if we want to be prepared for that eventuality, we should make
time_t map to d.
Anyway, what this all amounts to: If we standardize EXTERN:, we need
to standardize the mapping of C types to Forth types.
- 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 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-07-20 11:15 -0400 |
| Message-ID | <500975fa$0$295$14726298@news.sunsite.dk> |
| In reply to | #13973 |
Bernd Paysan wrote: > Stephen Pelc wrote: > >> Bernd said: [snip] >>> And I don't buy >>> into the "take the worst one, and stop using all the nice features you >>> actually need" approach. >> Neither do I, so why did you say that? > > Because you said that. You probably didn't realize it :-). You said, > your favorite is FSM, and we should stick to what it offers. Maybe > calling it "worst" is not really correct, it is one of the many pretty > limited OOF packages for Forth out there. What do you mean by "pretty limited"? > Which are all not only > syntactically incompatible, but also explore a different part of the OOP > universe. What are these different parts? > FMS is Doug's OOP package, it's coded for his > programming style. You give me far too much credit. FMS is essentially the long proven/used Neon-like model (whatever programming style that is) with the notable exceptions of object-message ordering, faster late binding, and multiple inheritance capability. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-07-20 20:18 +0200 |
| Message-ID | <juc7dq$6ul$1@online.de> |
| In reply to | #14211 |
Doug Hoffman wrote: > Bernd Paysan wrote: >> Because you said that. You probably didn't realize it :-). You >> said, >> your favorite is FSM, and we should stick to what it offers. Maybe >> calling it "worst" is not really correct, it is one of the many >> pretty limited OOF packages for Forth out there. > > What do you mean by "pretty limited"? Which means that you don't even understand how much it is limited :-). By looking at what we have so far as object oriented extensions, one thing became pretty obvious to me: They don't intersect that well. They all cover some aspects of OOP, and forget some others. Recommended reading is "Design Patterns" from the Gang of Four. If your OOP can do all these things, it can be considered sort-of complete. A few further design patterns have emerged since that book has been written. >> Which are all not only >> syntactically incompatible, but also explore a different part of the >> OOP universe. > > What are these different parts? This is the main problem I'm facing in this discussion: People know only their little world, and don't even understand that Java OOP, C++ OOP, and Smalltalk OOP are three quite different things. With some overlap. And then we have JavaScript/lua/Python OOPs, which are more prototype- based and explore something else. On the Forth side, we have discrepancies like implicit current object / explicit this pointer / object pointer on stack object method / method object global scoping / per-class scoping of selectors vt / hash table / wordlist early binding default / late binding default various styles of instance variables (Forth-like variables vs. object- like ones as in Neon) first class object pointers [+ multi-message passing] / cumersome object pointers / no object pointers at all selectors as xts / not usefully tickable dot-parsers / parsing words / non-parsing words single inheritance / interfaces / multiple inheritance and more. >> FMS is Doug's OOP package, it's coded for his >> programming style. > > You give me far too much credit. FMS is essentially the long > proven/used Neon-like model (whatever programming style that is) with > the notable exceptions of object-message ordering, faster late > binding, and multiple inheritance capability. Yes, and Neon makes me shudder. This was all completely wrong. You argue that it was proven, but I've looked at it back when it was "hot" and it was hate at the first sight. Now FMS fixes one of the worst offenders (message-object ordering). This is why the Common Lispers came up with their meta object protocol, because they couldn't find a consense, either. OOP is something even worse than Forth: It's not just a family of concepts under the same name, and this family has less in common than Forths have. The concept of a meta object protocol is to use OOP design principles to allow these different styles to coexist and build on common (but flexible) foundations. This is not about "I'm right and you are wrong", but it accepts that there are fundamental differences between different OOP packages. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-07-20 16:27 -0400 |
| Message-ID | <5009bf34$0$293$14726298@news.sunsite.dk> |
| In reply to | #14224 |
Bernd Paysan wrote: > Doug Hoffman wrote: > >> Bernd Paysan wrote: >>> Because you said that. You probably didn't realize it :-). You >>> said, >>> your favorite is FSM, and we should stick to what it offers. Maybe >>> calling it "worst" is not really correct, it is one of the many >>> pretty limited OOF packages for Forth out there. >> What do you mean by "pretty limited"? Bernd, I don't know how to make sense of your response. You are all over the map and have touched on a large number of cross-language issues that I'm not sure need to be weighted so heavily if at all. What is the end goal for *Forth*? Create the *perfect* object system that is all things to all programmers and somehow melds all existing and new cutting edge object ideas from all languages that support objects? That mindset is a setup for failure, read that as 30-50+ years or never to achieve a common Forth object system, caused by "analysis paralysis". > Which means that you don't even understand how much it is limited :-). I wonder if you understand what you want to say because you can't seem to put your thoughts into a few matter-of-fact sentences. Telling me to go read some books (I've read plenty) or go study 50 other programming languages is a dodge, not an answer. > By looking at what we have so far as object oriented extensions, one > thing became pretty obvious to me: They don't intersect that well. They > all cover some aspects of OOP, and forget some others. You are surprised that different object extensions have some differences? I'd be surprised if they didn't. > Recommended reading is "Design Patterns" from the Gang of Four. If your > OOP can do all these things, it can be considered sort-of complete. A > few further design patterns have emerged since that book has been > written. > >>> Which are all not only >>> syntactically incompatible, but also explore a different part of the >>> OOP universe. >> What are these different parts? > > This is the main problem I'm facing in this discussion: People know only > their little world, and don't even understand that Java OOP, C++ OOP, > and Smalltalk OOP are three quite different things. With some overlap. > And then we have JavaScript/lua/Python OOPs, which are more prototype- > based and explore something else. If you can't focus on *Forth* could you at least describe the particular details of OOP that you like in "languages A, B, C, ... "? Just saying they are different is not helpful. We know they are different. > On the Forth side, we have discrepancies like The following is the only part of your post that at least makes some sense because you describe the differences. What you don't talk about is which way you think Forth should go and why. > implicit current object / explicit this pointer / object pointer on > stack Object pointer on stack is most Forth-like IMO. It can be passed around as with any Forth item. I see no advantage to implicitly assumed objects. Explicit this (or self) makes the most sense. The principle of minimum astonishment (explicit behaviors) applies here quite well. > object method / method object Please. Have we not put this old non-issue to bed? > global scoping / per-class scoping of selectors I assume you mean scoping message names. The most flexible is message names with global scope. This allows for more seamless integration of objects/messages with normal Forth use. For example: : foo ( ^obj -- ) print ; \ print is a message. How can foo work without global message name scope? > vt / hash table / wordlist Implementation details. First decide how you want the object system to behave. Lastly, choose the implementation techniques that get the job done. > early binding default / late binding default This is a nit-pick detail. If the class of the object is known at compile time, what is the harm of allowing the compiler to invoke early binding? Besides, FMS as it is now fully supports late binding for *all* message sends if wanted. The programmer has complete control > various styles of instance variables (Forth-like variables vs. object- > like ones as in Neon) In case you hadn't noticed, FMS ivar primitives behave *exactly* like Forth variables. But if the ivar is declared to be an embedded object then its behavior is as an object. What is bad about this flexibility? > first class object pointers [+ multi-message passing] / cumersome object > pointers / no object pointers at all > > selectors as xts / not usefully tickable > > dot-parsers / parsing words / non-parsing words > > single inheritance / interfaces / multiple inheritance > > > and more. This is getting tedious. Why not just put together an objects package that behaves as you think it should. Provide rationale for your overall design decisions and detail design decisions. Can I assume that the ANS OOF package you ship with GForth represents that? I think that is a more productive approach than simply pointing out that different extensions have done some things differently. At the end of the day we have objects and messages. Hopefully we can agree on that without calling the other ignorant. Beyond that of course we have the issues of the relative ease of creating both. Perhaps most importantly, and I see not much discussion of this, are the higher level tasks that a good Forth object system should be able to address. Dynamically creating heap based objects as needed? Expandable/shrinkable object containers? Iterating over a list or sequence of anonymous objects? A discussion more like that. >>> FMS is Doug's OOP package, it's coded for his >>> programming style. >> You give me far too much credit. FMS is essentially the long >> proven/used Neon-like model (whatever programming style that is) with >> the notable exceptions of object-message ordering, faster late >> binding, and multiple inheritance capability. > > Yes, and Neon makes me shudder. This was all completely wrong. There you go again Bernd. You tell me it makes you shudder and is completely wrong. A cold wind makes me shudder. When someone says 2+2 is 5 then that is completely wrong. You just said nothing about Neon. > You > argue that it was proven, but I've looked at it back when it was "hot" > and it was hate at the first sight. Hate at first sight. Yes, now I understand the problem with a Neon-like approach. We can't have hate at first sight. That would certainly be a huge technical issue to solve. Maybe we can sprinkle "unhate dust" on it. > Now FMS fixes one of the worst > offenders (message-object ordering). As I keep telling you, that non-issue was put to bed years ago. > This is why the Common Lispers came up with their meta object protocol, > because they couldn't find a consense, either. OOP is something even > worse than Forth: It's not just a family of concepts under the same > name, and this family has less in common than Forths have. OK. So we are wasting our time even having this discussion. > The concept of a meta object protocol is to use OOP design principles to > allow these different styles to coexist and build on common (but > flexible) foundations. This is not about "I'm right and you are wrong", > but it accepts that there are fundamental differences between different > OOP packages. I think a multi-paradigm-super-flexible-whatever Forth objects package as a goal is a huge mistake. We will talk again about all of these same unresolved issues 20 years from now if that is the approach taken. But then I truly hope I am wrong about this and we will all be able to use this uber-objects system in a month or so. Shall I hold my breath? -Doug
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-07-21 00:21 +0200 |
| Message-ID | <juclkn$lr$1@online.de> |
| In reply to | #14229 |
Doug Hoffman wrote: > Bernd Paysan wrote: >> Doug Hoffman wrote: >> >>> Bernd Paysan wrote: >>>> Because you said that. You probably didn't realize it :-). You >>>> said, >>>> your favorite is FSM, and we should stick to what it offers. Maybe >>>> calling it "worst" is not really correct, it is one of the many >>>> pretty limited OOF packages for Forth out there. >>> What do you mean by "pretty limited"? > > Bernd, I don't know how to make sense of your response. You are all > over the map and have touched on a large number of cross-language > issues > that I'm not sure need to be weighted so heavily if at all. What is > the > end goal for *Forth*? To be an extensible and flexible interactive programming language that is minimalistic by design, yet does not people stop from extending it into whatever direction they want to. > Create the *perfect* object system that is all > things to all programmers and somehow melds all existing and new > cutting edge object ideas from all languages that support objects? The purpose of an extensible programming language is to allow users to extend it. If they want this or that feature, yes, they can. > That > mindset is a setup for failure, read that as 30-50+ years or never to > achieve a common Forth object system, caused by "analysis paralysis". No, come on. That's not the point. The point is to create a common basis to write Forth object systems in, which then can interact more easily than they do now. We already tried the "write an OOP system in isolation, and look if it takes over", and *that* approach failed. >> Which means that you don't even understand how much it is limited >> :-). > > I wonder if you understand what you want to say because you can't seem > to put your thoughts into a few matter-of-fact sentences. Telling me > to go read some books (I've read plenty) or go study 50 other > programming languages is a dodge, not an answer. Sorry, but the design patterns are *the* proof of the pudding of an object oriented system. If you can't be bothered to read that book, look up Wikipedia, it's a lot more condensed there. Actually, it's one of the few books about object oriented programming which is really important. >> By looking at what we have so far as object oriented extensions, one >> thing became pretty obvious to me: They don't intersect that well. >> They all cover some aspects of OOP, and forget some others. > > You are surprised that different object extensions have some > differences? I'd be surprised if they didn't. I'm not surprised. I just want to tell you that yours isn't for everybody. Neither is mine. > If you can't focus on *Forth* Forth is just extensible. You can implement any OOP style in Forth. > could you at least describe the > particular > details of OOP that you like in "languages A, B, C, ... "? Just > saying > they are different is not helpful. We know they are different. This is a Usenet posting, there is a limited amount of time. I can't give you the basic education you seem to lack. I did mention particular details of different style OOP systems (in Forth, but that are the difference in other languages, too) below, and you did comment on them. >> On the Forth side, we have discrepancies like > > The following is the only part of your post that at least makes some > sense because you describe the differences. What you don't talk about > is which way you think Forth should go and why. I know which way I want to go, and you know which way you want to go. Wwe don't meet at the same place. This was a failure. The common Lisper had the same problem: Lisp is an extensible and very flexible language. Different problems require different styles of programming, so one size fits all won't work. >> implicit current object / explicit this pointer / object pointer on >> stack > > Object pointer on stack is most Forth-like IMO. It can be passed > around > as with any Forth item. I see no advantage to implicitly assumed > objects. Explicit this (or self) makes the most sense. The principle > of minimum astonishment (explicit behaviors) applies here quite well. From my experience, implicit is what makes most sense. Most references within an object are to itself (own instance variables, own methods), not to some other object. The idea behind an object is that it is some sort of small module with words and variables, and while you are "inside" that object, these behave just like normal Forth words or variables. The current object pointer (the this pointer) is the context you are in. Most OOP systems use it for instance variable accesses, but for method invocations, it's not used that often. Mini-OOF has object pointers on the stack - it's all explicit. It's too cumbersome. Anton's objects have implicit this for instance variables and explicit for methods - it's a mix between both concepts. I've looked at his examples, and the majority of method invocations uses this as reference. People are good at contexts. This is not astonishing. When I ask my girl-friend, what she's doing, she texts me "shopping", "watching TV", or "taking a bath". No "I'm" involved. Because this is not necessary in this context, and brevity is king. We have nice grammatical rules in our text-books, but don't use them in oral language. That's one of *my* primary objections I have to FMS - it looks so much different from normal Forth. It does not need to. When you ask me for a direction, where Forth should be going, then this is one: OOP stuff should not just look different, because it's OOP. You need some boilerplate for a class, but you don't need to repeat that every line. >> object method / method object > > Please. Have we not put this old non-issue to bed? object method has won. >> global scoping / per-class scoping of selectors > > I assume you mean scoping message names. The most flexible is message > names with global scope. This allows for more seamless integration of > objects/messages with normal Forth use. For example: > > : foo ( ^obj -- ) > print ; \ print is a message. How can foo work without global > message name scope? Well, please: This is one school of OOP - the duck-type Smalltalk school. The other school is trying to tell you that interfaces matter, and objects may or may not implement a particular interface, and that it's good to have these scopes separated, because otherwise you end up with conflicts in your namespace. Also, maximum flexibility is only one end of the optimization space, maximum speed is another. >> vt / hash table / wordlist > > Implementation details. First decide how you want the object system > to > behave. Lastly, choose the implementation techniques that get the job > done. That's ok if you want only one object system at a time. However, as Stephen Pelc noticed, libraries that use OOP techniques come with their own OOP system. How to use two of these libraries at once? The OOP systems need to coexist. >> early binding default / late binding default > > This is a nit-pick detail. If the class of the object is known at > compile time, what is the harm of allowing the compiler to invoke > early binding? You can optimize as you like. The whole point is that "early binding default" overoptimizes - it makes that choice even when it is not appropriate, forcing the programmer to write something different if he doesn't want early binding. > Besides, FMS as it is now fully supports late binding for > *all* message sends if wanted. The programmer has complete control Yes, the point is *if wanted*. You assume that the programmer usually doesn't want this. That's the wrong way round. Assume the programmer usually wants this, and optimize if you can prove that it is not necessary. If the programmer wants to hand-optimize something where he knows which class is used, and the compiler can't know, give him the tools. Then it's "late binding default". >> various styles of instance variables (Forth-like variables vs. >> object- like ones as in Neon) > > In case you hadn't noticed, FMS ivar primitives behave *exactly* like > Forth variables. But if the ivar is declared to be an embedded object > then its behavior is as an object. What is bad about this > flexibility? FMS does a right step here, too. In Neon, ivars weren't normal Forth variables. >> first class object pointers [+ multi-message passing] / cumersome >> object pointers / no object pointers at all >> >> selectors as xts / not usefully tickable >> >> dot-parsers / parsing words / non-parsing words >> >> single inheritance / interfaces / multiple inheritance >> >> >> and more. > > This is getting tedious. Why not just put together an objects package > that behaves as you think it should. I've done this, 20 years ago. It's now christianed BerndOOF by Stephen Pelc, because it really does what *I* want. Other people want something different. They all can't fully agree. > Provide rationale for your overall > design decisions and detail design decisions. Can I assume that the > ANS OOF package you ship with GForth represents that? Yes. > I think that is a > more productive approach than simply pointing out that different > extensions have done some things differently. At the end of the day > we > have objects and messages. Hopefully we can agree on that without > calling the other ignorant. We all can learn new tricks. > Beyond that of course we have the issues > of > the relative ease of creating both. Perhaps most importantly, and I > see not much discussion of this, are the higher level tasks that a > good > Forth object system should be able to address. That's the point about design pattern, which I addressed at the beginning of my message. Yes, this is important. > Dynamically creating heap based objects as needed? Of course. > Expandable/shrinkable object containers? Certainly. > Iterating over a list or sequence of anonymous objects? I got accused of illegal return-stack tricks when doing that. We have this discussion as part of the quotations thread. Yes, yes, yes, we all need that. > A discussion more like that. Now you seem much more positive about this sort of discussion than at the start of the message. Yes, the proof of the pudding of an OOP system is what kind of higher-level stuff, called "design patterns", you can do with it. To discuss that, you should understand what design patterns are, and which design patterns have been identified. Iterators are a design pattern. >> Yes, and Neon makes me shudder. This was all completely wrong. > > There you go again Bernd. You tell me it makes you shudder and is > completely wrong. A cold wind makes me shudder. When someone says > 2+2 > is 5 then that is completely wrong. You just said nothing about Neon. It simply got nothing of the elementary design decisions "right". Not a single one. "Right" as: what I would do. Elementary decisions like order of method and object. Late and early binding. Instance variables. The way you define selectors. I simply was overwealmed, maybe I overlooked one or two correct design decisions. Sometimes, programs can make me shudder, too. >> You >> argue that it was proven, but I've looked at it back when it was >> "hot" and it was hate at the first sight. > > Hate at first sight. Yes, now I understand the problem with a > Neon-like > approach. We can't have hate at first sight. That would certainly be > a > huge technical issue to solve. Maybe we can sprinkle "unhate dust" on > it. No, just don't have your design upside down all over the place. I do feel something when I program, when I see other's code, and I do get emotional. >> Now FMS fixes one of the worst >> offenders (message-object ordering). > > As I keep telling you, that non-issue was put to bed years ago. If this had been a non-issue, it would have been put to bed a lot earlier. >> This is why the Common Lispers came up with their meta object >> protocol, >> because they couldn't find a consense, either. OOP is something even >> worse than Forth: It's not just a family of concepts under the same >> name, and this family has less in common than Forths have. > > OK. So we are wasting our time even having this discussion. Maybe. The point is that it *is* possible to build common foundations even when the implementation details *and* the design decisions differ. OOP is quite good at having this flexibility. >> The concept of a meta object protocol is to use OOP design principles >> to allow these different styles to coexist and build on common (but >> flexible) foundations. This is not about "I'm right and you are >> wrong", but it accepts that there are fundamental differences between >> different OOP packages. > > I think a multi-paradigm-super-flexible-whatever Forth objects package > as a goal is a huge mistake. That's not the goal. The goal is a Lego toolbox of simple bricks to build whatever you want to, and still have it fit together with other Lego bricks. > We will talk again about all of these > same > unresolved issues 20 years from now if that is the approach taken. > But then I truly hope I am wrong about this and we will all be able to > use > this uber-objects system in a month or so. Shall I hold my breath? You don't even understand why it's called "meta". You are confusing it with the "do everything"-machine in Thinking Forth. I'm not holding my breath. A meta object protocol is a toolbox to build object oriented systems. In such a way that you can hide your internal design decisions when others use yours. E.g. if you decide to have your methods take an object on the stack, and I decide to have my methods to use the current object pointer, and I call one of your methods, it will (because it is called in my context) use the current object pointer. Well, by pushing it to the stack, of course (so it's not an expensive operation and it is done at compile- time). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-07-20 19:49 -0400 |
| Message-ID | <5009ee8d$0$295$14726298@news.sunsite.dk> |
| In reply to | #14232 |
Bernd Paysan wrote: > Doug Hoffman wrote: > >> Bernd Paysan wrote: >>> early binding default / late binding default >> This is a nit-pick detail. If the class of the object is known at >> compile time, what is the harm of allowing the compiler to invoke >> early binding? > > You can optimize as you like. The whole point is that "early binding > default" overoptimizes - it makes that choice even when it is not > appropriate, forcing the programmer to write something different if he > doesn't want early binding. This is wrong. Early binding is *not* the default in FMS. FMS will *never* use early binding when it shouldn't. >> Besides, FMS as it is now fully supports late binding for >> *all* message sends if wanted. The programmer has complete control > > Yes, the point is *if wanted*. You assume that the programmer usually > doesn't want this. That's the wrong way round. Assume the programmer > usually wants this, and optimize if you can prove that it is not > necessary. If the programmer wants to hand-optimize something where he > knows which class is used, and the compiler can't know, give him the > tools. Then it's "late binding default". You are obsessing over a somewhat unimportant detail. I will try to explain. First, the context is method definitions inside a class definition. I believe we are talking about late binding to self ( in FMS we would use [SELF] ) vs early binding to self ( in FMS we would use SELF ). First let me say that one could easily eliminate [SELF] in FMS and simply have SELF be a late bind. I would wager that all class library code and Hayes testing code would still give correct answers. The only downside would be the code would be somewhat slowler. But late binding is fast in FMS so we may not care. Now consider a specific case. Say we have an expandable array object, a , and we wish to know how many elements are in a. We send the SIZE: message: "a size: . 5 ok" So we know we have 5 elements in a. How might the size: method in our array class be written? It could be written as "[self] size:" which is your preferred technique because it uses a late bound message to self. The size: method must be defined somewhere in the array class or in a superclass. You would not like "self size:" because that is early bound. OK. I understand that. I would expect that if you were to define a class in FMS one would never see SELF, just [SELF]. Because neither is *default* and Bernd does not like SELF. Now consider this. What if the size of the expandable array were kept in an instance variable named SIZE, which is likely. We could elect to use methodless ivar accessing and just use "size @" as the method definition. What? No late binding? Heck, this isn't even early binding. This is NO BINDING AT ALL! So I assume that you do not subscribe to methodless instance variable accessing, right? My bottom line. I really don't care much if FMS can early bind to self or not. If enough people asked for it I could just pull that feature in 5 minutes or less. Actually anyone could. Or just never use SELF ( use [SELF] instead, always). Would you be satisfied with that? But what are we to make of methodless ivar accessing? Do we ban that as well because it does not use late binding (or even early binding)? I have more comments on your post but it will come later. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-07-21 15:42 +0200 |
| Message-ID | <juebl4$he5$1@online.de> |
| In reply to | #14234 |
Doug Hoffman wrote: > You are obsessing over a somewhat unimportant detail. No, it's not unimportant, and I'm grumpy, because I feel like talking to walls. The reason why you think it's unimportant is that FMS is designed in such a way that it is difficult to use, so you don't actually use it. I consider this as a good example where the Sapir-Whorf hypothesis actually works: If your programming language does not allow you to express certain things, you won't use them and you won't miss them. A programming language is an artificial language, and if its expressive power is limited, people using it won't know (for natural languages, the Sapir-Whorf hypothesis is just wrong). Unless of course, they have learned other programming languages. > I will try to explain. First, the context is method definitions > inside > a class definition. I believe we are talking about late binding to > self ( in FMS we would use [SELF] ) vs early binding to self ( in FMS > we > would use SELF ). First let me say that one could easily eliminate > [SELF] in FMS and simply have SELF be a late bind. Yes, it could be done, but it hasn't been done. The point is: Unless the compiler knows which class to use, method calls have to be late bound. Since your FMS does have a current object (the ivars use it), you could say "a plain vanilla method, without any scope given, will be compiled late binding to the current object". Then you can keep SELF and SUPER as they are - as scope definers for the current defined class and its superclass. Methods with a defined scope are bound at compile time (which is called "early"), as their scope is known at compile time. Using [self] for late binding is particularly confusing, as [] notation usually says "do it at compile time". Here, you want to say "bound at run time", whereas the non-bracketed self binds at compile time. > Now consider a specific case. Say we have an expandable array object, You are confused. With usual OOP design, you don't have these specific cases. It's better to say "we have a container object" here. It might be an expandable array, a hash, or a list. Whatever it is, it has a size: method (inherited from container). > a > , and we wish to know how many elements are in a. We send the SIZE: > message: "a size: . 5 ok" So we know we have 5 elements in a. How > might the size: method in our array class be written? It could be > written as "[self] size:" which is your preferred technique because it > uses a late bound message to self. The size: method must be defined > somewhere in the array class or in a superclass. You would not like > "self size:" because that is early bound. OK. I understand that. I > would expect that if you were to define a class in FMS one would never > see SELF, just [SELF]. Because neither is *default* and Bernd does > not like SELF. It's clearly at least a wrong choice of names. > Now consider this. What if the size of the expandable array were kept > in an instance variable named SIZE, which is likely. We could elect > to use methodless ivar accessing and just use "size @" as the method > definition. What? No late binding? Heck, this isn't even early > binding. This is NO BINDING AT ALL! So I assume that you do not > subscribe to methodless instance variable accessing, right? It's Forth, you can do whatever you like. You are allowed to write bad programs, Forth compilers don't have a police department. However, I think the main trouble here is that FMS does not have first-class object pointers, so you can't even make good use of late binding. You have objects as instance variables, but by instantiation, they have a defined class. So there's no point in late binding, because the compiler knows what class it is. And since you do not offer an easy way to actually benefit from polymorphism, you don't get into situations where you would need it. Please think of it as "container". You instantiate a container in your class, and you don't know in advance what sort of container it will actually be. List, array, hash: these are possible containers. They have a common interface, and size: would be one of their methods. For an array, all you do is size @, but for a list, you need to walk it and for a hash, you need to sum up the counts of the lists in each bucket. > My bottom line. I really don't care much if FMS can early bind to > self > or not. If enough people asked for it I could just pull that feature > in > 5 minutes or less. Actually anyone could. Or just never use SELF ( > use > [SELF] instead, always). Would you be satisfied with that? But what > are we to make of methodless ivar accessing? Do we ban that as well > because it does not use late binding (or even early binding)? Well, it depends on which school you are in. In your Smalltalk duck- type school, methodless ivar accessing is completely out of question - because the ivar is within a scope of a certain class, while the method is in a global scope. So you can access the ivar only when you are within the scope of the class, i.e. while you are defining it. If you are in the interface-scope school, you can have ivars in the interface declaration. If you do so, the ivar is directly accessible. It's considered bad style, but sometimes it might be worth doing. Example: You want to cache access to slow external interfaces like SPI or I²C. You create a cache class, which has two methods: @: and !: (in FMS terms, I don't like to mark methods with :, methods are just Forth words). And an ivar: cache. You can directly access the cache, which gives you the last value read. As this follows the interface school, using the ivar directly is ok. It's meant for performance, and the interface school puts both methods and ivars into the same scope. Using whatever that scope provides is ok. Putting an ivar into a public scope might considered "bad style". But it's legal. Usually, you would define the interface without the ivars - the ivars are part of the implementation, i.e. the private scope of the class, not its public scope. > I have more comments on your post but it will come later. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-07-23 21:02 -0400 |
| Message-ID | <500df430$0$288$14726298@news.sunsite.dk> |
| In reply to | #14246 |
Bernd Paysan wrote: > Doug Hoffman wrote: >> You are obsessing over a somewhat unimportant detail. > > No, it's not unimportant, and I'm grumpy, because I feel like talking to > walls. The reason why you think it's unimportant is that FMS is > designed in such a way that it is difficult to use, so you don't > actually use it. > > I consider this as a good example where the Sapir-Whorf hypothesis > actually works: If your programming language does not allow you to > express certain things, you won't use them and you won't miss them. A > programming language is an artificial language, and if its expressive > power is limited, people using it won't know (for natural languages, the > Sapir-Whorf hypothesis is just wrong). Unless of course, they have > learned other programming languages. > >> I will try to explain. First, the context is method definitions >> inside >> a class definition. I believe we are talking about late binding to >> self ( in FMS we would use [SELF] ) vs early binding to self ( in FMS >> we >> would use SELF ). First let me say that one could easily eliminate >> [SELF] in FMS and simply have SELF be a late bind. > > Yes, it could be done, but it hasn't been done. The point is: Unless > the compiler knows which class to use, method calls have to be late > bound. Since your FMS does have a current object (the ivars use it), > you could say "a plain vanilla method, without any scope given, will be > compiled late binding to the current object". Then you can keep SELF > and SUPER as they are - as scope definers for the current defined class > and its superclass. Methods with a defined scope are bound at compile > time (which is called "early"), as their scope is known at compile time. > > Using [self] for late binding is particularly confusing, as [] notation > usually says "do it at compile time". Here, you want to say "bound at > run time", whereas the non-bracketed self binds at compile time. > >> Now consider a specific case. Say we have an expandable array object, > > You are confused. With usual OOP design, you don't have these specific > cases. It's better to say "we have a container object" here. It might > be an expandable array, a hash, or a list. Whatever it is, it has a > size: method (inherited from container). > >> a >> , and we wish to know how many elements are in a. We send the SIZE: >> message: "a size: . 5 ok" So we know we have 5 elements in a. How >> might the size: method in our array class be written? It could be >> written as "[self] size:" which is your preferred technique because it >> uses a late bound message to self. The size: method must be defined >> somewhere in the array class or in a superclass. You would not like >> "self size:" because that is early bound. OK. I understand that. I >> would expect that if you were to define a class in FMS one would never >> see SELF, just [SELF]. Because neither is *default* and Bernd does >> not like SELF. > > It's clearly at least a wrong choice of names. > >> Now consider this. What if the size of the expandable array were kept >> in an instance variable named SIZE, which is likely. We could elect >> to use methodless ivar accessing and just use "size @" as the method >> definition. What? No late binding? Heck, this isn't even early >> binding. This is NO BINDING AT ALL! So I assume that you do not >> subscribe to methodless instance variable accessing, right? > > It's Forth, you can do whatever you like. You are allowed to write bad > programs, Forth compilers don't have a police department. However, I > think the main trouble here is that FMS does not have first-class object > pointers, so you can't even make good use of late binding. You have > objects as instance variables, but by instantiation, they have a defined > class. So there's no point in late binding, because the compiler knows > what class it is. And since you do not offer an easy way to actually > benefit from polymorphism, you don't get into situations where you would > need it. > > Please think of it as "container". You instantiate a container in your > class, and you don't know in advance what sort of container it will > actually be. List, array, hash: these are possible containers. They > have a common interface, and size: would be one of their methods. For > an array, all you do is size @, but for a list, you need to walk it and > for a hash, you need to sum up the counts of the lists in each bucket. > >> My bottom line. I really don't care much if FMS can early bind to >> self >> or not. If enough people asked for it I could just pull that feature >> in >> 5 minutes or less. Actually anyone could. Or just never use SELF ( >> use >> [SELF] instead, always). Would you be satisfied with that? But what >> are we to make of methodless ivar accessing? Do we ban that as well >> because it does not use late binding (or even early binding)? > > Well, it depends on which school you are in. In your Smalltalk duck- > type school, methodless ivar accessing is completely out of question - > because the ivar is within a scope of a certain class, while the method > is in a global scope. So you can access the ivar only when you are > within the scope of the class, i.e. while you are defining it. > > If you are in the interface-scope school, you can have ivars in the > interface declaration. If you do so, the ivar is directly accessible. > It's considered bad style, but sometimes it might be worth doing. > > Example: You want to cache access to slow external interfaces like SPI > or I²C. You create a cache class, which has two methods: @: and !: (in > FMS terms, I don't like to mark methods with :, methods are just Forth > words). And an ivar: cache. You can directly access the cache, which > gives you the last value read. > > As this follows the interface school, using the ivar directly is ok. > It's meant for performance, and the interface school puts both methods > and ivars into the same scope. Using whatever that scope provides is > ok. Putting an ivar into a public scope might considered "bad style". > But it's legal. > > Usually, you would define the interface without the ivars - the ivars > are part of the implementation, i.e. the private scope of the class, not > its public scope. > >> I have more comments on your post but it will come later. > I keep looking for this "limited capability" of FMS that you originally spoke of. You haven't described any yet. You don't like the choice of some names, but that is not capability. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2012-07-23 21:31 -0400 |
| Message-ID | <500dfaf9$0$284$14726298@news.sunsite.dk> |
| In reply to | #14246 |
Bernd Paysan wrote: > Well, it depends on which school you are in. In your Smalltalk duck- > type school, methodless ivar accessing is completely out of question - > because the ivar is within a scope of a certain class, while the method > is in a global scope. So you can access the ivar only when you are > within the scope of the class, i.e. while you are defining it. This is incorrect. FMS allows easy access to instance variables *outside* of the class definition. Have you ever actually *seen* FMS? You don't need to read the source. Just skim the class library and perhaps some of the Hayes tests. http://soton.mpeforth.com/flag/fms/index.html Only look at " Download: FMS Single & Multiple Inheritance .zip Packages" -Doug
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2012-07-21 01:18 -0700 |
| Message-ID | <3adeb3ab-7c58-4c96-9d48-c51bfa4f053e@googlegroups.com> |
| In reply to | #14232 |
On Saturday, July 21, 2012 12:21:10 AM UTC+2, Bernd Paysan wrote: > Doug Hoffman wrote: [..] This *style* of discussion is absolutely not doing anything to make me want to experiment with OOP techniques, regardless of the merits they may have, and regardless of whom is proposing them. Maybe the discussion could start at the other end. I have a challenge for the both of you. (I don't know if it is really suitable for OOP or not). I'd like to use the GTK+ library on Windows/Linux/OSX to build user interfaces. I expect to provide a text description of what I want a gadget to look like, together with the xt of existing Forth words for any actions that need to be performed. An interface to run code from dynamically linked C (not C++) libraries may be assumed existing, as does some sort of callback mechanism. It should be possible to load the GTK+ functionality as "marker -a include gtk include test -a" , and then the Forth is unchanged (and all gadgets are gone). Note that I didn't say which Forth system I am going to use. Can this be done with present Forth OOP (regardless of how it is implemented)? Please show me (a small example is good enough). If extra (system) functionality is needed, it is enough to show a Forth interface specification for it, as long as it does not depend implicitly on internal details of the OOP package (I would be impressed/interested even more). -marcel
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-07-21 11:59 +0000 |
| Message-ID | <m7ienu.efn@spenarnc.xs4all.nl> |
| In reply to | #14237 |
In article <3adeb3ab-7c58-4c96-9d48-c51bfa4f053e@googlegroups.com>, <mhx@iae.nl> wrote: >On Saturday, July 21, 2012 12:21:10 AM UTC+2, Bernd Paysan wrote: >> Doug Hoffman wrote: >[..] > >This *style* of discussion is absolutely not doing anything to make me want= > to experiment with OOP techniques, regardless of the merits they may have,= > and regardless of whom is proposing them. > >Maybe the discussion could start at the other end. I have a challenge for t= >he both of you. (I don't know if it is really suitable for OOP or not). > >I'd like to use the GTK+ library on Windows/Linux/OSX to build user interfa= >ces. I expect to provide a text description of what I want a gadget to look= > like, together with the xt of existing Forth words for any actions that ne= >ed to be performed. An interface to run code from dynamically linked C (not= > C++) libraries may be assumed existing, as does some sort of callback mech= >anism. It should be possible to load the GTK+ functionality as "marker -a i= >nclude gtk include test -a" , and then the Forth is unchanged (and all gadg= >ets are gone). Note that I didn't say which Forth system I am going to use. > >Can this be done with present Forth OOP (regardless of how it is implemente= >d)? Please show me (a small example is good enough). If extra (system) func= >tionality is needed, it is enough to show a Forth interface specification f= >or it, as long as it does not depend implicitly on internal details of the = >OOP package (I would be impressed/interested even more). Please limit line length to 70 chars. I like the idea of having an object / class testcase for different OO, but your proposal is way too involved. My proposal: Define an initialised object with two fields and setters, getters for the fields. Sample code for, creation, getting and setting, and interference between different objects. Show decompilation of an object, decompilation of the methods implemented (set,get), decompilation of ``this'' or equivalent, decompilation of how an anonymous object is created. I'll go first, see separate thread, forthcoming. > >-marcel -- -- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-07-21 14:43 +0200 |
| Message-ID | <jue84o$jum$1@online.de> |
| In reply to | #14237 |
mhx@iae.nl wrote: > On Saturday, July 21, 2012 12:21:10 AM UTC+2, Bernd Paysan wrote: >> Doug Hoffman wrote: > [..] > > This *style* of discussion is absolutely not doing anything to make me > want to experiment with OOP techniques, regardless of the merits they > may have, and regardless of whom is proposing them. I don't like this style of discussion, either. It is so difficult to get an argument through. I remember the discussion with Klaus Schleisiek - he had a very limited understanding of what OOP is, and it took considerable amount of time to convince him that late binding actually is useful. Stephen Pelc on EuroForth said "I don't know much about OOP, but I propose to use FMS". > Maybe the discussion could start at the other end. I have a challenge > for the both of you. (I don't know if it is really suitable for OOP or > not). It is. > I'd like to use the GTK+ library on Windows/Linux/OSX to build user > interfaces. I expect to provide a text description of what I want a > gadget to look like, together with the xt of existing Forth words for > any actions that need to be performed. An interface to run code from > dynamically linked C (not C++) libraries may be assumed existing, as > does some sort of callback mechanism. It should be possible to load > the GTK+ functionality as "marker -a include gtk include test -a" , > and then the Forth is unchanged (and all gadgets are gone). Note that > I didn't say which Forth system I am going to use. Manfred Mahlow implemented a GTK+ interface with his OOP system (which is pretty simple). Not even late binding necessary. I'm not sure if Manfred's system supports marker, but Klaus Schleisiek ported his OOP system to Gforth. Create GTK+ bindings with Swig, and you probably should be able to use Manfred's sources. > Can this be done with present Forth OOP (regardless of how it is > implemented)? Please show me (a small example is good enough). If > extra (system) functionality is needed, it is enough to show a Forth > interface specification for it, as long as it does not depend > implicitly on internal details of the OOP package (I would be > impressed/interested even more). There's an article in VD 2008/02 (download it from forth-ev.de). And that's his hello world listing: \ Listing 2: Gtk+-Beispiel "Hello World" in Forth needs GtkWindow needs GtkButton oop definitions gtk api decimal :: ( wid data -- ) ." Hello World" cr ; 2 20 cb cb.hello :: ( wid data -- ) gtk quit ; 2 20 cb cb.destroy GtkWindow new window GtkButton new button : main ( -- ) GTK_WINDOW_TOPLEVEL window init " destroy" cb.destroy 0 window signal connect drop 10 window border-width ! " Hello World " button init window add " clicked" cb.hello 0 button signal connect drop window show all term? 0if gtk main bye then ; main oop ?? -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2012-07-21 19:36 +0000 |
| Message-ID | <m7izt6.6te@spenarnc.xs4all.nl> |
| In reply to | #14245 |
In article <jue84o$jum$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote: <SNIP> > >There's an article in VD 2008/02 (download it from forth-ev.de). And >that's his hello world listing: > >\ Listing 2: Gtk+-Beispiel "Hello World" in Forth > >needs GtkWindow >needs GtkButton > >oop definitions gtk api decimal > >:: ( wid data -- ) ." Hello World" cr ; 2 20 cb cb.hello > >:: ( wid data -- ) gtk quit ; 2 20 cb cb.destroy > >GtkWindow new window >GtkButton new button > >: main ( -- ) > GTK_WINDOW_TOPLEVEL window init > " destroy" cb.destroy 0 window signal connect drop > 10 window border-width ! > " Hello World " button init window add > " clicked" cb.hello 0 button signal connect drop > window show all > term? 0if gtk main bye then >; > >main oop ?? You really have to tell more about this. For instance I can't even make out if you consider this recommended or avoidable code. You could start with telling us what is supposedly seen on a screen when you run it. > >-- >Bernd Paysan Groetjes Albert -- -- 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-07-21 21:41 +0200 |
| Message-ID | <juf0kp$mmk$1@online.de> |
| In reply to | #14251 |
Albert van der Horst wrote: > In article <jue84o$jum$1@online.de>, Bernd Paysan > <bernd.paysan@gmx.de> wrote: <SNIP> >> >>There's an article in VD 2008/02 (download it from forth-ev.de). And >>that's his hello world listing: >> >>\ Listing 2: Gtk+-Beispiel "Hello World" in Forth >> >>needs GtkWindow >>needs GtkButton >> >>oop definitions gtk api decimal >> >>:: ( wid data -- ) ." Hello World" cr ; 2 20 cb cb.hello >> >>:: ( wid data -- ) gtk quit ; 2 20 cb cb.destroy >> >>GtkWindow new window >>GtkButton new button >> >>: main ( -- ) >> GTK_WINDOW_TOPLEVEL window init >> " destroy" cb.destroy 0 window signal connect drop >> 10 window border-width ! >> " Hello World " button init window add >> " clicked" cb.hello 0 button signal connect drop >> window show all >> term? 0if gtk main bye then >>; >> >>main oop ?? > > You really have to tell more about this. For instance I can't > even make out if you consider this recommended or avoidable > code. You could start with telling us what is supposedly seen > on a screen when you run it. Manfred has written an entire article, and since you are too lazy to dig out the link yourself, here it is (to the entire VD): http://www.forth-ev.de/filemgmt/visit.php?lid=198 German, but you can read that. This is a hello world thing, so expect a "Hello World" button in a window. I haven't written these GTK+ bindings, and reading the article was quite some time ago, but I can figure out from the code what it is supposed to do. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.forth
csiph-web