Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #3564 > unrolled thread
| Started by | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| First post | 2011-06-26 15:13 -0500 |
| Last post | 2011-07-02 17:52 +0000 |
| Articles | 20 on this page of 308 — 43 participants |
Back to article view | Back to comp.lang.forth
The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-26 15:13 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:13 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 15:50 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 16:55 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-06-27 17:23 +0000
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-27 20:09 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-29 18:59 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 12:49 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:38 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-03 11:27 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-03 17:40 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 18:38 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-06-30 12:25 -0700
Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 09:43 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-12 12:35 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:02 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Doug Hoffman <glidedog@gmail.com> - 2011-07-14 08:32 -0400
Re: Forth OO ( was: Re: The Lisp Curse ) Alex McDonald <blog@rivadpm.com> - 2011-07-14 07:10 -0700
Re: Forth OO ( was: Re: The Lisp Curse ) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 09:31 -0500
Re: The Lisp Curse arc@vorsicht-bissig.de - 2011-07-12 22:20 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 03:02 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-27 21:29 -1000
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-28 06:55 -0400
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 06:17 -0500
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-28 14:14 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-06-30 16:08 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-01 13:41 -1000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 21:18 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:26 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 16:56 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-02 08:28 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-02 17:00 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-03 10:20 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-04 20:57 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-06 15:45 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 16:19 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 01:23 +0000
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:44 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-06 19:01 -0700
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-07-07 10:39 +0000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-07 13:07 -0700
Re: The Lisp Curse "David N. Williams" <williams@umich.edu> - 2011-07-06 21:42 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-07 10:32 +0100
Re: The Lisp Curse marko <marko@marko.marko.marko> - 2011-07-07 22:09 +1000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 09:19 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:08 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 10:33 +0100
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-08 05:31 -0500
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 17:47 +0100
Re: The Lisp Curse vandys@vsta.org - 2011-07-08 17:23 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-08 15:34 -0400
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:04 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-08 10:34 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-08 21:28 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-09 15:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-10 10:14 +0100
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-10 22:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 03:18 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-11 12:42 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-12 19:42 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-12 14:42 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-07-11 07:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 07:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-11 20:40 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-11 21:24 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-12 18:54 -0700
Re: The Lisp Curse Ron Aaron <rambamist@gmail.com> - 2011-07-12 20:45 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-13 00:28 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-13 10:25 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-11 19:55 +0100
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 13:41 -0700
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-07-11 13:45 -0700
Re: The Lisp Curse Jan Coombs <jan_2011-02@murray-microft.co.uk> - 2011-07-12 21:51 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-09 16:49 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-11 04:27 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-07 14:53 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-28 11:57 +0100
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-07-29 21:54 -0700
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-07-30 18:22 -0500
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-01 12:59 +0000
Re: The Lisp Curse Julian Fondren <ayrnieu@gmail.com> - 2011-08-02 00:07 -0500
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-01 22:58 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-08 20:44 -0700
Re: The Lisp Curse Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-07-31 10:25 +0100
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-08 16:00 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-10 07:08 -1000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-10 18:01 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 03:05 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 07:37 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 10:07 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:32 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:25 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:37 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:15 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 08:02 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-11 08:13 -0700
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 18:50 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-12 01:39 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-11 10:06 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-11 08:02 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 11:49 +0000
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-12 13:18 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-12 18:49 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-12 12:52 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-14 09:54 -0400
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 12:53 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-14 13:21 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-14 15:09 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 04:52 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-15 03:46 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 12:15 +0000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-15 20:51 +0200
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-15 21:56 +0000
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-15 19:50 -0700
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:07 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:45 -0700
Re: The Lisp Curse arc <arc@vorsicht-bissig.de> - 2011-08-18 11:38 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-18 07:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-15 06:01 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-16 05:10 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-16 03:13 -0700
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-08-18 23:31 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 06:09 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 17:14 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:38 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-20 20:49 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-20 23:39 -0700
Re: The Lisp Curse "Jeff M." <massung@gmail.com> - 2011-08-21 00:29 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 00:57 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 01:04 -0700
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 16:12 +0000
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-21 13:21 +0200
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 10:40 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:56 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:33 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 12:42 -0700
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-21 13:30 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 12:49 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-21 13:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:48 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-22 10:36 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 22:57 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-22 23:28 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-08-23 04:16 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 08:29 -0500
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 16:54 +0000
Re: The Lisp Curse Doug Hoffman <glidedog@gmail.com> - 2011-08-23 10:48 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-21 13:49 -0400
Re: The Lisp Curse George Hubert <georgeahubert@yahoo.co.uk> - 2011-08-22 01:49 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-22 17:02 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 07:50 -1000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-23 01:03 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-22 22:38 -1000
Hamming numbers (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-22 15:10 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 00:09 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-19 17:41 +0000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-19 18:05 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-19 13:53 -0500
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-19 13:15 -0700
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 15:39 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-19 19:49 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-19 17:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-20 03:54 -0400
Re: The Lisp Curse Josh Grams <josh@qualdan.com> - 2011-08-20 15:20 +0000
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-21 14:41 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 11:47 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-08-22 20:30 +0200
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 15:22 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-22 23:34 -0400
Re: The Lisp Curse Hugh Aguilar <hughaguilar96@yahoo.com> - 2011-08-22 22:48 -0700
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-20 08:55 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 10:49 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:03 +0000
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-14 07:57 -0700
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-12 09:51 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 13:45 +0000
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-13 08:08 -1000
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-08-14 02:56 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-13 04:35 -0500
Re: The Lisp Curse Keith H Duggar <duggar@alum.mit.edu> - 2011-08-12 07:53 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-13 14:13 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-13 13:59 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-14 14:46 +0000
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-08-17 01:31 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-06-28 03:24 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201106.rodent.frell.theremailer.net> - 2011-06-28 19:55 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 06:30 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 13:49 +0100
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-29 14:02 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:16 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-06-29 15:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 19:45 -0400
Re: The Lisp Curse Elko T <nono.black.elko@gmail.com> - 2011-06-29 22:08 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 10:07 -0400
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-06-30 20:44 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 18:08 -0400
Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 20:07 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-06-30 22:12 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:01 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 17:59 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) The Beez <the.beez.speaks@gmail.com> - 2011-07-01 16:33 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:37 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) kenney@cix.compulink.co.uk - 2011-07-01 06:07 -0500
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:00 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-01 14:06 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-01 14:57 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 16:55 +0000
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-01 16:04 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 11:26 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) coos haak <chforth@hccnet.nl> - 2011-07-02 22:10 +0200
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-02 14:36 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-02 21:36 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-02 18:25 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-03 10:53 -0700
Re: Counted vs. terminated strings (Re: The Lisp Curse) Elko T <nono.black.elko@gmail.com> - 2011-07-04 23:41 -0400
Re: Counted vs. terminated strings (Re: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:02 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-02 22:46 +0200
Re: The Lisp Curse David Thompson <dave.thompson2@verizon.net> - 2011-07-18 01:25 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-06-30 14:44 +0100
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 23:24 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-03 12:04 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-03 20:24 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 02:21 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-04 16:02 +0200
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 10:21 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:13 -0700
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-04 12:31 -0700
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 15:01 -0700
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-04 13:23 -1000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 01:45 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 11:34 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 05:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-05 14:28 +0000
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:39 -0700
OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 15:36 +0000
Re: OT: full virtualization Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 13:17 -0500
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:53 -0700
Re: OT: full virtualization anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-08 17:11 +0000
Re: OT: full virtualization Alex McDonald <blog@rivadpm.com> - 2011-07-08 12:41 -0700
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-08 04:34 -0700
Re: OT: full virtualization (was: The Lisp Curse) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-10 16:03 +0000
Re: OT: full virtualization (was: The Lisp Curse) Alex McDonald <blog@rivadpm.com> - 2011-07-10 13:06 -0700
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-07 00:11 +0200
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-06 12:47 -1000
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-07 10:07 +0000
Re: The Lisp Curse Tarkin <tarkin000@gmail.com> - 2011-07-07 13:00 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 12:40 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-04 11:15 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-04 15:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 10:16 +0200
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 02:23 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 09:54 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 22:33 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 16:28 -0500
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 16:18 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-04 15:03 -0400
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-05 00:20 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-05 11:35 -0400
Re: The Lisp Curse Alex McDonald <blog@rivadpm.com> - 2011-07-05 09:46 -0700
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-05 23:13 +0200
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 15:31 -0700
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-05 19:21 -0500
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-07-05 14:57 -1000
Re: The Lisp Curse John Passaniti <john.passaniti@gmail.com> - 2011-07-05 20:48 -0700
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-06 07:38 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:46 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-07 10:41 -0500
Re: The Lisp Curse BruceMcF <agila61@netscape.net> - 2011-07-07 09:12 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-06 09:53 -0500
Re: The Lisp Curse Nomen Nescio <nobody@dizum.com> - 2011-07-06 21:45 +0200
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-07 14:48 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-07 20:20 +0100
Re: The Lisp Curse coos haak <chforth@hccnet.nl> - 2011-07-08 04:39 +0200
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-12 23:22 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-07-12 19:35 -0400
Re: The Lisp Curse Chris Hinsley <chris.hinsley@gmail.com> - 2011-07-13 23:37 +0100
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-12 05:10 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-12 03:44 -0500
Re: The Lisp Curse Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> - 2011-07-13 22:06 +0200
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-14 04:01 -0500
Re: The Lisp Curse kenney@cix.compulink.co.uk - 2011-07-07 04:38 -0500
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-03 07:34 -0500
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 13:25 -0400
Forth as implementation language vandys@vsta.org - 2011-06-29 18:27 +0000
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-29 17:50 -0400
Re: Forth as implementation language vandys@vsta.org - 2011-06-29 22:45 +0000
Re: Forth as implementation language Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:04 +0100
Re: Forth as implementation language Spam@ControlQ.com - 2011-06-30 11:42 -0400
Re: Forth as implementation language "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-30 13:12 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 08:38 -1000
Re: The Lisp Curse Spam@ControlQ.com - 2011-06-29 18:01 -0400
Re: The Lisp Curse Elizabeth D Rather <erather@forth.com> - 2011-06-29 12:50 -1000
Re: The Lisp Curse stephenXXX@mpeforth.com (Stephen Pelc) - 2011-06-30 08:15 +0000
Re: The Lisp Curse Spam@ControlQ.com - 2011-07-03 15:22 -0400
Re: The Lisp Curse Mark Wills <markrobertwills@yahoo.co.uk> - 2011-06-30 13:09 +0100
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-06-29 18:31 -0400
Re: The Lisp Curse Paul Rubin <no.email@nospam.invalid> - 2011-06-29 23:01 -0700
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-07-01 09:42 -0500
Re: The Lisp Curse Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-07-01 18:49 +0000
Re: The Lisp Curse Mentifex <mentifex@myuw.net> - 2011-06-29 15:41 -0700
Re: The Lisp Curse "Fuschia, President-Elect of the Bright Purplish-Green Council" <fp-eotbp-gc@ibm.com> - 2011-06-29 19:16 -0400
Re: The Lisp Curse Mark Wills <forthfreak@forthfiles.net> - 2011-06-30 00:34 -0700
Re: The Lisp Curse anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-07-02 17:52 +0000
Page 1 of 16 [1] 2 3 … 16 Next page →
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-06-26 15:13 -0500 |
| Subject | The Lisp Curse |
| Message-ID | <Ls-dncUCTbhjD5rTnZ2dnUVZ8kKdnZ2d@supernews.com> |
This is interesting, although I'm not sure I agree with all of it: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html "Imagine adding object orientation to the C and Scheme programming languages. Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup. "The consequences of this divergence in needed talent and effort cause The Lisp Curse: "Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp." Andrew.
[toc] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-27 16:13 +0100 |
| Message-ID | <2011062716133234957-chrishinsley@gmailcom> |
| In reply to | #3564 |
On 2011-06-26 21:13:50 +0100, Andrew Haley said: > This is interesting, although I'm not sure I agree with all of it: > > http://www.winestockwebdesign.com/Essays/Lisp_Curse.html > > "Imagine adding object orientation to the C and Scheme programming > languages. Making Scheme object-oriented is a sophomore homework > assignment. On the other hand, adding object orientation to C requires > the programming chops of Bjarne Stroustrup. > > "The consequences of this divergence in needed talent and effort cause > The Lisp Curse: > > "Lisp is so powerful that problems which are technical issues in other > programming languages are social issues in Lisp." > > Andrew. OK, as you've had no takers I'll bite. It was pretty easy to add object orientation to VP assembler, useing just assembler macros, back in 1990. So no I don't think it's that hard. :) Who was it that said, 'object orientation is just a bloody look up table...' ;) Chris
[toc] | [prev] | [next] | [standalone]
| From | vandys@vsta.org |
|---|---|
| Date | 2011-06-27 15:50 +0000 |
| Message-ID | <96rn58Fv50U1@mid.individual.net> |
| In reply to | #3577 |
Chris Hinsley <chris.hinsley@gmail.com> wrote: > Who was it that said, 'object orientation is just a bloody look up > table...' ;) I don't know, but in addition to dispatching the call, you need some methodology for instance variables. I wouldn't claim that OO is the fix to all programming ills, but at its best it does provide a lot of expressive power from a very modest set of core conepts. -- Andy Valencia Home page: http://www.vsta.org/andy/ To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-27 16:55 +0100 |
| Message-ID | <201106271655172796-chrishinsley@gmailcom> |
| In reply to | #3580 |
On 2011-06-27 16:50:00 +0100, vandys@vsta.org said: > Chris Hinsley <chris.hinsley@gmail.com> wrote: >> Who was it that said, 'object orientation is just a bloody look up >> table...' ;) > > I don't know, but in addition to dispatching the call, you need some > methodology for instance variables. I wouldn't claim that OO is the fix to > all programming ills, but at its best it does provide a lot of expressive > power from a very modest set of core conepts. OK, have a structure with the first item being a pointer to a look up table, etc etc. ;) I'm not dissing OO, I like it. Just that it's not hard to do even when the language your codeing in dosn't support it directly. However, reading the linked to article I feel Andrew might have posted this here in the Forth newsgroup because theres a lot of similar arguements for Forth ! Chris
[toc] | [prev] | [next] | [standalone]
| From | vandys@vsta.org |
|---|---|
| Date | 2011-06-27 17:23 +0000 |
| Message-ID | <96rsk5Fcf3U1@mid.individual.net> |
| In reply to | #3582 |
Chris Hinsley <chris.hinsley@gmail.com> wrote:
>> I don't know, but in addition to dispatching the call, you need some
>> methodology for instance variables.
> OK, have a structure with the first item being a pointer to a look up
> table, etc etc. ;)
It's more than that. If the superclass has ivars "a" and "b", then when you
subclass it and have your own ivars "c" and "d", instances of your subclass
have to have ivars "a".."d". Often when you allocate you want
instance-specific initialization of ivars, so you also have to have a way to
connect subclass initializing code to superclass code.
> I'm not dissing OO, I like it. Just that it's not hard to do even when
> the language your codeing in dosn't support it directly.
Speaking from experience, doing OO coding in Forth is harder than doing it in
Smalltalk. Or Java. Or Python. Forth is more like a very powerful macro
assembler on top of hand-coded assembly language for a CPU with a dual stack
architecture.
> However, reading the linked to article I feel Andrew might have posted
> this here in the Forth newsgroup because there's a lot of similar
> arguments for Forth!
I assume you mean:
http://forthos.org/oo.html
I found the OO abstractions helpful some of the time, but it was still a win
to port to Python and take advantage of a really impressive set of amenities,
both in the base language and its available libraries.
--
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-27 20:09 +0100 |
| Message-ID | <2011062720090650721-chrishinsley@gmailcom> |
| In reply to | #3587 |
On 2011-06-27 18:23:17 +0100, vandys@vsta.org said: > Chris Hinsley <chris.hinsley@gmail.com> wrote: >>> I don't know, but in addition to dispatching the call, you need some >>> methodology for instance variables. >> OK, have a structure with the first item being a pointer to a look up >> table, etc etc. ;) > > It's more than that. If the superclass has ivars "a" and "b", then when you > subclass it and have your own ivars "c" and "d", instances of your subclass > have to have ivars "a".."d". Often when you allocate you want > instance-specific initialization of ivars, so you also have to have a way to > connect subclass initializing code to superclass code. Yes, I know, and it was all implamentable in assembler macros. The VP assembler was pretty hot on what you could do in the macro system I grant you, but inheritance, constructors, destructors, superclass variable accsess, initialisation of all superclasses etc was all covered. One thing that it didn't do directly was multiple inheritance, but speaking personaly I never missed that. > >> I'm not dissing OO, I like it. Just that it's not hard to do even when >> the language your codeing in dosn't support it directly. > > Speaking from experience, doing OO coding in Forth is harder than doing it in > Smalltalk. Or Java. Or Python. Forth is more like a very powerful macro > assembler on top of hand-coded assembly language for a CPU with a dual stack > architecture. I agree with you on the Forth is a powerful macro assembler, which is why I don't think it's any harder to do OOP in Forth than it was in assembler code. > >> However, reading the linked to article I feel Andrew might have posted >> this here in the Forth newsgroup because there's a lot of similar >> arguments for Forth! > > I assume you mean: > http://forthos.org/oo.html > > I found the OO abstractions helpful some of the time, but it was still a win > to port to Python and take advantage of a really impressive set of amenities, > both in the base language and its available libraries. I wasn't refering to any implamentation of OOP in Forth. In the article (which I assume you've read) it was more pointing out that the flexability of Lisp (and I belive this carries over to Forth) works against it in getting anything done long term. You only ever end up with 80% solutions to a problem as someone allways just does it there way because it's so easy to define your own rather than agree and co-operate with other people useing the langauge... I, like Andrew Haley, don't agree with all of the article, but it's sentiment is just as true for Forth as it is for Lisp. Chris
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-06-29 18:59 -0700 |
| Message-ID | <7d15ed97-e9d5-40b4-b642-666716056ec9@s17g2000yqs.googlegroups.com> |
| In reply to | #3587 |
On Jun 27, 11:23 am, van...@vsta.org wrote: > Chris Hinsley <chris.hins...@gmail.com> wrote: > > I'm not dissing OO, I like it. Just that it's not hard to do even when > > the language your codeing in dosn't support it directly. > > Speaking from experience, doing OO coding in Forth is harder than doing it in > Smalltalk. Or Java. Or Python. Forth is more like a very powerful macro > assembler on top of hand-coded assembly language for a CPU with a dual stack > architecture. The two fundamental aspects of OO are inheritance and polymorphism. Inheritance is pretty easy; I did that extensively in my novice package, although I did have to rewrite ALLOCATE and friends to support an ALLOCATION function. Polymorphism is more difficult. You generally use local variables in your functions, and arrange for these locals to have type declarations attached to them, so that when you call a member function you get the one that is associated with that type. This works, but it is not very Forth-like. Normally in Forth you don't use local variables very much, but just keep the data on the stack. Forth OO code, with its extensive use of locals, doesn't look very much like Forth --- it looks like a postfix-version of Object Pascal. I think that Forth's primary use is in micro-controllers. Considering that Object Pascal never was used in micro-controllers, a Forth version isn't going to be used much either. I would really prefer a very light-weight OO Forth, such as I used in my novice package. This is still in keeping with the Forth spirit (short functions with little or no use of locals), but you do get inheritance. Most micro- controller applications aren't complex enough to really need polymorphism, which assumes a lot of classes with name collisions between them. On the other hand, there are a lot of micro-controller applications that are complex enough to need inheritance, which assumes data structures in which not all of the nodes are the same type (you have both parent and child nodes in there). Traditionally in both Forth and C, this was accomplished by making a union of the parent and child data types (as promoted by Rob Pemberton). This wastes memory, and it is just cheesy --- you are better off to use inheritance, which is the *correct* way. The OO system presented in my novice package is the Goldilocks solution. It is more complex than the use of unions, but it is less complex than a full-blown OO system with polymorphism --- it is just the right size for most applications (that you would be using Forth for in the first place). That article that Andrew Haley referenced was about Lisp. There is some similarity between Forth and Lisp in so much as they both allow the programmer to write code that executes at compile-time --- they are traditionally the only two extensible languages available. There isn't much similarity in usage though. Forth is a much more down-to- earth language --- it is primarily used for controlling machinery, it runs just fine on 8-bit and 16-bit processors, and it is often done by electrical engineers who are more interested in hardware than in software. Lisp is very high-brow --- it is primarily used for AI, it runs on 32-bit and 64-bit processors, and it is often done by men with ponytails who can't even change the oil in their car. The culture is completely different. Forthers drink beer and Lispers drink white wine. Forthers still think that the 65c02 is a great processor (and know the instruction set by heart), and Lispers think that 64-bit processors are mandatory for serious programming (but don't know the instruction set at all).
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2011-06-30 12:49 +0100 |
| Message-ID | <TdCdnSXTI_pT_5HTnZ2dnUVZ7v2dnZ2d@bt.com> |
| In reply to | #3661 |
On 30/06/2011 02:59, Hugh Aguilar wrote: > Forthers still think that the 65c02 is a great processor (and > know the instruction set by heart), and Lispers think that 64-bit > processors are mandatory for serious programming (but don't know the > instruction set at all). I always thought it was a terrible processor! Quick though for what it was. Imagine what it could have been with a decent set of registers....
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-02 16:38 -0700 |
| Message-ID | <82466b42-20c6-49a3-b9d8-1db6249163b9@q17g2000vby.googlegroups.com> |
| In reply to | #3666 |
On Jun 30, 5:49 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote: > On 30/06/2011 02:59, Hugh Aguilar wrote: > > > Forthers still think that the 65c02 is a great processor (and > > know the instruction set by heart), and Lispers think that 64-bit > > processors are mandatory for serious programming (but don't know the > > instruction set at all). > > I always thought it was a terrible processor! Quick though for what it > was. Imagine what it could have been with a decent set of registers.... On the 65c02, the zero-page could be used as 16-bit soft-registers for pointing at data. That was ahead of its time. The 65C02 didn't allow the location of the soft-registers to be changed, which would have been nice (the 65C816 did), but it was still a pretty good design. This is all immaterial now. The 8-bit processors are obsolete now, so nobody cares if Forth runs on them or not. The 16-bit processors are on their way toward becoming obsolete too. We still have processors such as the PIC24 in use, but they will disappear pretty soon. I didn't predict this. It seems like just a little while ago that 8-bit processors (especially the 80c320) were the standard, 16-bit processors (such as the MC6812) were the heavy hitters, and 32-bit processors were unheard of (in the micro-controller world). I expected that 16-bit processors would become the standard (and I was glad of it, as most of those 8-bit processors were too limited), but that 32- bit processors would never be used as micro-controllers. Now 32-bit processors are the standard. I could write a Forth for the PIC24, but doing so would be somewhat pointless. The PIC24 will soon be obsolete, along with all of the other 16-bit processors. When 16-bit processors become obsolete, Forth will become obsolete too. There are myriad powerful languages available for 32-bit processors. Who is going to want to use a language that doesn't have *any* support for OOP? Of course, C will also become obsolete along with Forth, but that is not much of a consolation, considering that C++ will take its place. I tried to introduce ALLOCATION into Forth-200x in order to allow for inheritance, but this idea was killed because Forth has to be implementable in C and C doesn't have ALLOCATION. Imagine if ALLOCATION had been introduced into Forth in the late 1980s when OOP was first becoming popular. People would have flocked to Forth because they could have inheritance, and they would have abandoned C altogether. A quarter of a century later, Forth would be the standard language and nobody would care if Forth could be implemented in C or not, because C would have become obsolete long ago. I remember in 1984 that Forth and C were both popular, and it was anybody's guess which would become the standard. A failure in leadership in the Forth community resulted in Forth's complete failure. Now most people have never heard of Forth, but the few who have heard of it are only familiar with Gforth, which is just a toy --- it is slow as molasses compared to C (because it is written in C!) and it is unsuitable for any kind of application programming whatsoever. Almost everybody interested in Forth (including yourself) is interested in writing their own hobby Forth system (or in learning how Gforth works internally), but nobody is interested in writing applications. There are a few hobby applications, such as Sudoku solvers or my slide-rule program, but even those are rare --- there are more Forth systems being written than Forth applications, and almost none of those Forth systems are capable of being used to write Forth applications.
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2011-07-03 11:27 +0000 |
| Message-ID | <lnr95e.4gs@spenarnc.xs4all.nl> |
| In reply to | #3727 |
In article <82466b42-20c6-49a3-b9d8-1db6249163b9@q17g2000vby.googlegroups.com>, Hugh Aguilar <hughaguilar96@yahoo.com> wrote: >This is all immaterial now. The 8-bit processors are obsolete now, so >nobody cares if Forth runs on them or not. Like the humans are dwarfed by bacteria, not only in numbers, but in bio-mass, so you will be surprised by the number of 4 bit computers around, let alone 8 bits. You know nothing. <SNIP> 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 | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-07-03 17:40 -0700 |
| Message-ID | <346c97a6-6a26-43f0-9b9c-92a9d447114a@j23g2000yqc.googlegroups.com> |
| In reply to | #3736 |
On Jul 3, 7:27 am, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > Like the humans are dwarfed by bacteria, not only in > numbers, but in bio-mass, so you will be surprised by > the number of 4 bit computers around, let alone 8 > bits. You know nothing. A fun exercise that most anyone who believes that 8-bit systems are obsolete is to run through the electronic systems in one's home and determine how many by percentage are 8-bit (or as you point out less). Not sure if something is 8-bit? Open it up and see. When I've done this with people who made the same claim Hugh has, they are often surprised at the sheer number of 8-bit systems. And quite often, they miss quite a few because they don't consider the subcomponents in larger systems like desktop computers, monitors and televisions, cars, and so on. 8-bit systems are quite alive and well, and will be for many years to come. The reason is simple-- often, they are just the right size for the job at hand, and can do so with less system cost.
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2011-07-04 18:38 -0700 |
| Message-ID | <67b616f5-b491-4c68-86dc-8f26f81606d2@h38g2000pro.googlegroups.com> |
| In reply to | #3736 |
On Jul 3, 5:27 am, Albert van der Horst <alb...@spenarnc.xs4all.nl> wrote: > In article <82466b42-20c6-49a3-b9d8-1db624916...@q17g2000vby.googlegroups.com>, > Hugh Aguilar <hughaguila...@yahoo.com> wrote: > > >This is all immaterial now. The 8-bit processors are obsolete now, so > >nobody cares if Forth runs on them or not. > > Like the humans are dwarfed by bacteria, not only in numbers, but in > bio-mass, so you will be surprised by the number of 4 bit computers > around, let alone 8 bits. You know nothing. > > <SNIP> > > Groetjes Albert The 8-bit processors are used in mass-produced items because they are inexpensive. In mass-produced items, a few pennies savings can add up to quite a lot. In this case, the cost of hiring programmers to write the software is very small compared to the cost of manufacturing the item. The programming is a one-time cost that usually took place a long time ago (in many cases, the company no longer even has the source-code). Most such systems use an 8051 derivative, a small PIC chip, a COP8, etc., and they are written in assembly language --- those kinds of chips don't really support high-level languages. Most of the time, assembly language is used rather than an HHL to reduce memory usage because this allows a less expensive chip to be used. As I said, programming is a one-time cost, so if the use of assembly language rather than C or Forth doubles the cost of the software development, that is insignificant compared to the gain that is achieved by using a chip that is a few pennies less expensive than what would otherwise be used. Nobody cares if the source-code is readable or maintainable, because when mass-production of the item begins, the source-code will never be changed or even looked at again. The point that I'm making is that, while there may be a lot of 8-bit micro-controllers being manufactured and used, there is very little programming of 8-bit micro-controllers being done. There is not a whole lot of programming of 16-bit micro-controllers being done either --- pretty much all programming being done is of 32-bit micro- controllers, mostly the ARM, and mostly for onesy-twosy items. The fact that Forth can be used on 8-bit and 16-bit processors is irrelevant to the vast majority of programmers, because they use C on 32-bit processors. If they consider upgrading to a new language, it would most likely be to C++ or Java --- Forth isn't considered at all.
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-06-30 12:25 -0700 |
| Message-ID | <2219fbc4-ce19-47e9-a71b-ad5b2cfed347@e7g2000vbw.googlegroups.com> |
| In reply to | #3587 |
On Jun 27, 1:23 pm, van...@vsta.org wrote: > Speaking from experience, doing OO coding in Forth is harder > than doing it in Smalltalk. Or Java. Or Python. Forth is > more like a very powerful macro assembler on top of > hand-coded assembly language for a CPU with a dual stack > architecture. What I got out of "The Lisp Curse" article was that powerful languages (that is, languages that expose and let you maniplate the underlying mechanisms) lead developers to build-up exactly what they need. That great, but with every developer each implementing their own take on a feature (such as object orientation), what you get is that each only implement the portions of a feature that developer felt was important. Applying this to Forth, what you see is a number of different OO packages, each with disjoint features and syntax. And of course, the authors of these packages each think their particular set of features, syntax, optimizations, and so on are best. One of the things I find interesting about the Lua community is how they addressed this problem. The Lua language doesn't have any built- in notion of objects and-- like Lisp and Forth-- Lua is not an object- oriented language. What Lua does offer is a set of extensible mechanisms and some syntactic sugar related to objects. Like with Lisp and Forth, the Lua programmer is free to build up whatever kind of objects they see fit. If you think multiple inheritance class- based objects are cool, you can build that. If you like simpler prototype-based objects, you can build that. Early binding, late binding, protection mechanisms baked into the objects or left as a matter of convention, simple work-a-day objects or based on more exotic notions. If you think an object should inherit just code and not data, go for it. As practical or as insane as you want, you can do it. If you want to mix different kinds of objects, nothing stops you. But what is interesting about object orientation in the Lua world is that because it's all built on the same base, for the most part, all of these object models coexist peacefully. So for example, in the last major Lua-based project I worked on, most of the application code was written using a prototype-style of objects, but calling libraries that used class-style objects. And while there were a couple subtle and interesting edges there, it worked just fine. I wonder how Forth would be different today if at some point the community said, "we disagree what an object is and what an object should be, but we can find common ground in a core set of abstractions that we think are a suitable base for most object-based systems." Like with Lua, that wouldn't be an endorsement of any particular flavor of objects-- or even the use of objects at all. And it wouldn't stop passionate arguments for or against different object models. It's just the realization that there is a certain amount of conceptual overlap in most object systems, and that overlap could be standardized. The closest thing Forth offers to this is CREATE/DOES>. It's not the only way to create objects, but often plays a role in most designs. The problem is that it's too low-level. Nobody has gotten the various authors of Forth object systems together in a room, locked the doors, turned up the heat, and said, "you're not leaving here until you all come up with a core set of facilities that you agree are all useful in implementing objects." Had that happened-- either metaphorically or in fact-- where would Forth be today?
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2011-07-12 09:43 -0400 |
| Subject | Forth OO ( was: Re: The Lisp Curse ) |
| Message-ID | <4e1c4f85$0$304$14726298@news.sunsite.dk> |
| In reply to | #3675 |
On 6/30/11 3:25 PM, John Passaniti wrote:
> What I got out of "The Lisp Curse" article was that powerful languages
> (that is, languages that expose and let you maniplate the underlying
> mechanisms) lead developers to build-up exactly what they need. That
> great, but with every developer each implementing their own take on a
> feature (such as object orientation), what you get is that each only
> implement the portions of a feature that developer felt was
> important.
Yes, that was pretty much my take as well. It could be viewed as both a
blessing and a curse. The blessing being that it can be relatively easy
to implement powerful extensions. The curse being that the efforts are
not always coordinated and can lead to redundancy of effort and
functionality and (worse) incompatibilities. Taken to the extreme, I
suppose, we have programmers preferring to create an entire custom Forth
rather than just using one of the excellent available
professional-quality Forths. I'm not knocking that necessarily because
each should choose how to spend their available time.
Stephen Pelc's FLAG effort is an excellent platform for centralizing the
awareness and availability of existing code and code libraries.
http://soton.mpeforth.com/flag/index.html
> Applying this to Forth, what you see is a number of
> different OO packages, each with disjoint features and syntax.
Yes. The same applies to other Forth extensions such as strings, lists,
and arrays just to name just a few.
> And of
> course, the authors of these packages each think their particular set
> of features, syntax, optimizations, and so on are best.
>
> One of the things I find interesting about the Lua community is how
> they addressed this problem. The Lua language doesn't have any built-
> in notion of objects and-- like Lisp and Forth-- Lua is not an object-
> oriented language. What Lua does offer is a set of extensible
> mechanisms and some syntactic sugar related to objects. Like with
> Lisp and Forth, the Lua programmer is free to build up whatever kind
> of objects they see fit. If you think multiple inheritance class-
> based objects are cool, you can build that. If you like simpler
> prototype-based objects, you can build that.
Prototype-based objects sound interesting. You've mentioned them
before. I gather that once the prototype-based object is constructed
its use is no different than a class-based object. I.e., the object has
its own data and the object responds to messages.
I've tried to glean the fundamental advantage of the prototype route by
searching the net but a clear explanation seems elusive. There is
mention that creating a new object with inherited/changed behavior is
easier, or something like that. Makes me wonder why that should be the
case. Perhaps in some languages, or specific object extensions, the
creation of new classes is not as simple as it ought to be?
I would be interesting in seeing some Forth pseudo-words with just their
behavior descriptions in general terms (no code required) that would
lead to the flexibility spoken of in Lua.
-Doug
> Early binding, late
> binding, protection mechanisms baked into the objects or left as a
> matter of convention, simple work-a-day objects or based on more
> exotic notions. If you think an object should inherit just code and
> not data, go for it. As practical or as insane as you want, you can
> do it. If you want to mix different kinds of objects, nothing stops
> you.
>
> But what is interesting about object orientation in the Lua world is
> that because it's all built on the same base, for the most part, all
> of these object models coexist peacefully. So for example, in the
> last major Lua-based project I worked on, most of the application code
> was written using a prototype-style of objects, but calling libraries
> that used class-style objects. And while there were a couple subtle
> and interesting edges there, it worked just fine.
>
> I wonder how Forth would be different today if at some point the
> community said, "we disagree what an object is and what an object
> should be, but we can find common ground in a core set of abstractions
> that we think are a suitable base for most object-based systems."
> Like with Lua, that wouldn't be an endorsement of any particular
> flavor of objects-- or even the use of objects at all. And it
> wouldn't stop passionate arguments for or against different object
> models. It's just the realization that there is a certain amount of
> conceptual overlap in most object systems, and that overlap could be
> standardized.
>
> The closest thing Forth offers to this is CREATE/DOES>. It's not the
> only way to create objects, but often plays a role in most designs.
> The problem is that it's too low-level. Nobody has gotten the various
> authors of Forth object systems together in a room, locked the doors,
> turned up the heat, and said, "you're not leaving here until you all
> come up with a core set of facilities that you agree are all useful in
> implementing objects." Had that happened-- either metaphorically or
> in fact-- where would Forth be today?
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2011-07-12 12:35 -0400 |
| Subject | Re: Forth OO ( was: Re: The Lisp Curse ) |
| Message-ID | <4e1c77cf$0$316$14726298@news.sunsite.dk> |
| In reply to | #4046 |
On 7/12/11 9:43 AM, Doug Hoffman wrote: > I would be interesting in seeing some Forth pseudo-words with just their > behavior descriptions in general terms (no code required) that would > lead to the flexibility spoken of in Lua. I would also be *interested* in the same. (Egad). -Doug
[toc] | [prev] | [next] | [standalone]
| From | John Passaniti <john.passaniti@gmail.com> |
|---|---|
| Date | 2011-07-13 10:02 -0700 |
| Subject | Re: Forth OO ( was: Re: The Lisp Curse ) |
| Message-ID | <59dbb425-7a44-4207-a606-b3d8bb22b26e@x10g2000vbl.googlegroups.com> |
| In reply to | #4046 |
On Jul 12, 9:43 am, Doug Hoffman <glide...@gmail.com> wrote: > Prototype-based objects sound interesting. You've mentioned > them before. I gather that once the prototype-based object > is constructed its use is no different than a class-based > object. I.e., the object has its own data and the object > responds to messages. Yes, in terms of actual use, a prototype-based object isn't really any different. The difference comes during construction; instead of making instances of classes, you take existing objects, clone them, and modify them as needed. Depending on the specifics of the language, that clone operation can be a literal copy, or it might be a pointer back to the parent object(s), or it might be a method cache, or something else. But regardless of the mechanisms, the primary advantage of prototype-based objects over class-based ones is that you don't have to frame your solutions in terms of class hierarchies. It also results in a simpler language, because you don't have classes and instances as two separate things. You just have objects. What appeals to me about prototype-based systems over class-based ones is that nothing stops you from creating classes if you want. When a solution naturally calls out for classes, you just create an object that serves as the prototype for that class and create clones. Semantically, it ends up being pretty much the same. But you're not limited to that. When you have one-off objects or when you have instances of a class that you want to individually tweak, you can. > I've tried to glean the fundamental advantage of the prototype > route by searching the net but a clear explanation seems elusive. > There is mention that creating a new object with inherited/changed > behavior is easier, or something like that. Makes me wonder why > that should be the case. Perhaps in some languages, or specific > object extensions, the creation of new classes is not as simple as > it ought to be? Let's take a real-world example from where I work. In a digital audio system, we have a DSP. On this DSP, we have a variety of signal processing algorithms (delays, filters, compressors, etc.). When expressed as objects, there are certain aspects of these DSP algorithms that are common. They all have a name, take up a certain number of cycles, they all have an address in the DSP where the algorithm's code and coefficients are located. So for the common parts, it makes sense to define an abstract base class. Great. But when we start to dive into the individual DSP algorithms, we start to see differences. A simple delay has a single parameter (delay time). A parametric filter might have four parameters (filter type, center frequency, Q, gain). A FIR filter has zero parameters, but does have a coefficient table. Some DSP algoritms don't affect audio in any way, but do measurements (like meters). Other DSP algorithms generate audio (such as noise generators). Some DSP algorithms act as routers of audio streams. And so on. You can model all this using more classes-- and sometimes this makes sense. You might start with general classes of DSP algorithms (like those that affect audio, those that generate audio, and those that measure audio). Within these, you might have more classes that further specialize (like delay and filter classes). And within those, yet more specialization and so on. Then someone tosses in a curve-ball. We have a special DSP algorithm that has properties of both one that affects audio and one that measures audio (like a feedback suppressor). Well that's a problem because we had started off with classes that make a clear distinction between those two kinds of algorithms, and now we have one that mixes aspects of them together. So now we have to juggle things around-- instead of being classes, maybe these are interfaces. Or maybe now we get into multiple inheritance if the language supports that. And that might affect subclasses. Grrrr... The second curve-bass is thrown. Some audio problems are handled by combining combinations of DSP algorithms. Take for example a speaker crossover; it is actually two or more filters that work together. We want the user to see these aggregations of DSP algorithms as a single algorithm. Our class hierarchy doesn't really have any such notion, so maybe we come up with an entirely new base class so we can go back and add a way to aggregate subclasses. More juggling around. Maybe it works. And maybe it makes sense. Certainly the common parts make sense as classes. But the unique parts can drive the need to create artificial classes that exist only to capture the differences. And that's when classes start to feel clunky. They served you well as long as there were gross areas of commonality, but when things started to get more specialized, you were creating new classes because that's the only tool in your class-based toolbox. With prototypes, you are free to use classes up until the point where they don't make sense. If a particular DSP algorithm varies only slightly from other, you can capture that variation by directly modifying an object. Or if you have a one-off special case that is completely different from everything else, you don't have to go back to your class hierarchy and force it to fit. You can reach into the object, change what you need, and off you go. > I would be interesting in seeing some Forth pseudo-words with > just their behavior descriptions in general terms (no code > required) that would lead to the flexibility spoken of in Lua. I think I wrote about this in the past. But I think the same idea used in Lua would apply equally well to Forth. The Lua authors have a philosophy of "separating mechanism from policy." Or put another way, what they did was to factor object orientation itself and break it down into it's essential parts. You would think that idea would appeal to Forth programmers who pride themselves on factoring, but the object systems available for Forth don't really do that. They combine mechansim and policy into one thing, and that one thing says what an object is and how it works. Outside of Lua's factoring of object orientation, I've found there are others who are exploring this space. One of the better ones is found in "Open, Extensible Object Models" (see http://piumarta.com/software/cola/objmodel2.pdf). This paper doesn't just offer a flexible system, but also talks about making it efficient. What's important in this paper is how they broke down objects into a core set of facilities that you can then build on. The implementation is in C, but there isn't much there that is specific to C.
[toc] | [prev] | [next] | [standalone]
| From | Doug Hoffman <glidedog@gmail.com> |
|---|---|
| Date | 2011-07-14 08:32 -0400 |
| Subject | Re: Forth OO ( was: Re: The Lisp Curse ) |
| Message-ID | <4e1ee1e8$0$316$14726298@news.sunsite.dk> |
| In reply to | #4110 |
On 7/13/11 1:02 PM, John Passaniti wrote: > On Jul 12, 9:43 am, Doug Hoffman<glide...@gmail.com> wrote: >> Prototype-based objects sound interesting. You've mentioned >> them before. I gather that once the prototype-based object >> is constructed its use is no different than a class-based >> object. I.e., the object has its own data and the object >> responds to messages. > > Yes, in terms of actual use, a prototype-based object isn't really any > different. The difference comes during construction; instead of > making instances of classes, you take existing objects, clone them, > and modify them as needed. So far, not really different than taking an existing *class* and modifying *it* as needed. Once you have the class, then you have the object: they are synonymous. > Depending on the specifics of the > language, that clone operation can be a literal copy, I assume care is taken when cloning an object that contains pointers to allocated memory. A common situation. Or perhaps it is normal practice to manually initialize each cloned object. > or it might be a > pointer back to the parent object(s), or it might be a method cache, > or something else. But regardless of the mechanisms, the primary > advantage of prototype-based objects over class-based ones is that you > don't have to frame your solutions in terms of class hierarchies.It > also results in a simpler language, because you don't have classes and > instances as two separate things. You just have objects. With prototype-based objects you don't "just have objects", right? There must also be code written to give the different objects their behaviors and data. So it must be that writing that proto-code is simpler, in practice and concept, than writing class-code. It's a little hard to see, at least for me right now, but I certainly don't doubt that that could be the case. > What appeals to me about prototype-based systems over class-based ones > is that nothing stops you from creating classes if you want. When a > solution naturally calls out for classes, you just create an object > that serves as the prototype for that class and create clones. > Semantically, it ends up being pretty much the same. But you're not > limited to that. When you have one-off objects or when you have > instances of a class that you want to individually tweak, you can. Creating a one-off 'tweaked' class for a one-off object is something I've often done. It's not hard to do. But this assumes that one has a class-creation facility that is easy to use. >> I've tried to glean the fundamental advantage of the prototype >> route by searching the net but a clear explanation seems elusive. >> There is mention that creating a new object with inherited/changed >> behavior is easier, or something like that. Makes me wonder why >> that should be the case. Perhaps in some languages, or specific >> object extensions, the creation of new classes is not as simple as >> it ought to be? > > Let's take a real-world example from where I work. > > In a digital audio system, we have a DSP. On this DSP, we have a > variety of signal processing algorithms (delays, filters, compressors, > etc.). When expressed as objects, there are certain aspects of these > DSP algorithms that are common. They all have a name, take up a > certain number of cycles, they all have an address in the DSP where > the algorithm's code and coefficients are located. So for the common > parts, it makes sense to define an abstract base class. Great. > > But when we start to dive into the individual DSP algorithms, we start > to see differences. A simple delay has a single parameter (delay > time). A parametric filter might have four parameters (filter type, > center frequency, Q, gain). A FIR filter has zero parameters, but > does have a coefficient table. Some DSP algoritms don't affect audio > in any way, but do measurements (like meters). Other DSP algorithms > generate audio (such as noise generators). Some DSP algorithms act as > routers of audio streams. And so on. > > You can model all this using more classes-- Yes. > and sometimes this makes > sense. You might start with general classes of DSP algorithms (like > those that affect audio, those that generate audio, and those that > measure audio). Within these, you might have more classes that > further specialize (like delay and filter classes). And within those, > yet more specialization and so on. > > Then someone tosses in a curve-ball. We have a special DSP algorithm > that has properties of both one that affects audio and one that > measures audio (like a feedback suppressor). Well that's a problem > because we had started off with classes that make a clear distinction > between those two kinds of algorithms, and now we have one that mixes > aspects of them together. So now we have to juggle things around-- > instead of being classes, maybe these are interfaces. Or maybe now we > get into multiple inheritance if the language supports that. I find that using embedded objects-as-ivars can get you most of the advantage of multiple inheritance. It's not as convenient because one has to write pass-through methods that call on the ivars. With MI you don't, unless there are message name collisions. > And that > might affect subclasses. Grrrr... No. Don't do that. Changing an existing class that is known to be relied upon by other subclasses is really not a good idea. Instead "clone" the class (a.k.a. make a subclass of it) and change *that* instead. > The second curve-bass is thrown. Some audio problems are handled by > combining combinations of DSP algorithms. Take for example a speaker > crossover; it is actually two or more filters that work together. We > want the user to see these aggregations of DSP algorithms as a single > algorithm. Our class hierarchy doesn't really have any such notion, > so maybe we come up with an entirely new base class so we can go back > and add a way to aggregate subclasses. Yes. > More juggling around. Ok. > Maybe it works. And maybe it makes sense. Certainly the common parts > make sense as classes. But the unique parts can drive the need to > create artificial classes that exist only to capture the differences. > And that's when classes start to feel clunky. They served you well as > long as there were gross areas of commonality, but when things started > to get more specialized, you were creating new classes because that's > the only tool in your class-based toolbox. > > With prototypes, you are free to use classes up until the point where > they don't make sense. If a particular DSP algorithm varies only > slightly from other, you can capture that variation by directly > modifying an object. Or if you have a one-off special case that is > completely different from everything else, you don't have to go back > to your class hierarchy and force it to fit. You can reach into the > object, change what you need, and off you go. Sounds good. Can't say that I've had problems using classes, but then I probably don't know what I'm missing because I've not used prototypes. Nice explanation though. Thanks. >> I would be interesting in seeing some Forth pseudo-words with >> just their behavior descriptions in general terms (no code >> required) that would lead to the flexibility spoken of in Lua. > > I think I wrote about this in the past. But I think the same idea > used in Lua would apply equally well to Forth. The Lua authors have a > philosophy of "separating mechanism from policy." Or put another way, > what they did was to factor object orientation itself and break it > down into it's essential parts. You would think that idea would > appeal to Forth programmers who pride themselves on factoring, but the > object systems available for Forth don't really do that. They combine > mechansim and policy into one thing, and that one thing says what an > object is and how it works. That is true. Perhaps we need a champion for creating these "factored" generic Forth OO words. > Outside of Lua's factoring of object orientation, I've found there are > others who are exploring this space. One of the better ones is found > in "Open, Extensible Object Models" (see http://piumarta.com/software/cola/objmodel2.pdf). > This paper doesn't just offer a flexible system, but also talks about > making it efficient. What's important in this paper is how they broke > down objects into a core set of facilities that you can then build > on. The implementation is in C, but there isn't much there that is > specific to C. Thanks for the link. It's the best explanation of these ideas I've seen. -Doug
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-14 07:10 -0700 |
| Subject | Re: Forth OO ( was: Re: The Lisp Curse ) |
| Message-ID | <7c62352a-45d1-4bab-bc4b-9db148e48a66@gh5g2000vbb.googlegroups.com> |
| In reply to | #4147 |
On Jul 14, 1:32 pm, Doug Hoffman <glide...@gmail.com> wrote: > On 7/13/11 1:02 PM, John Passaniti wrote: > [snippage] > > > Outside of Lua's factoring of object orientation, I've found there are > > others who are exploring this space. One of the better ones is found > > in "Open, Extensible Object Models" (seehttp://piumarta.com/software/cola/objmodel2.pdf). > > This paper doesn't just offer a flexible system, but also talks about > > making it efficient. What's important in this paper is how they broke > > down objects into a core set of facilities that you can then build > > on. The implementation is in C, but there isn't much there that is > > specific to C. > > Thanks for the link. It's the best explanation of these ideas I've seen. > > -Doug It also appears to be very amenable to the Forth treatment. Very clear and concise paper, thanks for link.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2011-07-14 09:31 -0500 |
| Subject | Re: Forth OO ( was: Re: The Lisp Curse ) |
| Message-ID | <vfWdna55Ca8kYIPTnZ2dnUVZ_uqdnZ2d@supernews.com> |
| In reply to | #4152 |
Alex McDonald <blog@rivadpm.com> wrote: > On Jul 14, 1:32?pm, Doug Hoffman <glide...@gmail.com> wrote: >> On 7/13/11 1:02 PM, John Passaniti wrote: >> > [snippage] >> >> > Outside of Lua's factoring of object orientation, I've found >> > there are others who are exploring this space. ?One of the better >> > ones is found in "Open, Extensible Object Models" (see >> > http://piumarta.com/software/cola/objmodel2.pdf). This paper >> > doesn't just offer a flexible system, but also talks about making >> > it efficient. ?What's important in this paper is how they broke >> > down objects into a core set of facilities that you can then >> > build on. ?The implementation is in C, but there isn't much there >> > that is specific to C. >> >> Thanks for the link. ?It's the best explanation of these ideas I've seen. > > It also appears to be very amenable to the Forth treatment. Yes, it does. The key book IMO is "The Art of the Metaobject Protocol", which is a pretty mind-expanding experience. If you've not read it, I strongly recommend that you do. It explains a lot of the motivation behind extensible object models and implies that most contemporary OO languages are, er, wrong. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | arc@vorsicht-bissig.de |
|---|---|
| Date | 2011-07-12 22:20 -0700 |
| Message-ID | <d9fc6d6f-cc44-4c15-84a4-324121cba2f3@a31g2000vbt.googlegroups.com> |
| In reply to | #3675 |
On Jul 1, 7:25 am, John Passaniti <john.passaniti@gmail.com> wrote: > One of the things I find interesting about the Lua community is how > they addressed this problem. The Lua language doesn't have any built- > in notion of objects and-- like Lisp and Forth-- Lua is not an object- > oriented language. What Lua does offer is a set of extensible > mechanisms and some syntactic sugar related to objects. Like with > Lisp and Forth, the Lua programmer is free to build up whatever kind > of objects they see fit. If you think multiple inheritance class- > based objects are cool, you can build that. If you like simpler > prototype-based objects, you can build that. Early binding, late > binding, protection mechanisms baked into the objects or left as a > matter of convention, simple work-a-day objects or based on more > exotic notions. If you think an object should inherit just code and > not data, go for it. As practical or as insane as you want, you can > do it. If you want to mix different kinds of objects, nothing stops > you. > > But what is interesting about object orientation in the Lua world is > that because it's all built on the same base, for the most part, all > of these object models coexist peacefully. So for example, in the > last major Lua-based project I worked on, most of the application code > was written using a prototype-style of objects, but calling libraries > that used class-style objects. And while there were a couple subtle > and interesting edges there, it worked just fine. This sounds really interesting, John - both the fact that the Lua community have agreed on object abstractions which don't imply any particular object paradigm, and that you've used two different paradigms in the same project. This project wouldn't be an open source one, by any chance, would it?
[toc] | [prev] | [next] | [standalone]
Page 1 of 16 [1] 2 3 … 16 Next page →
Back to top | Article view | comp.lang.forth
csiph-web