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 324 — 44 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 Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:20 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:15 -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 Alex McDonald <blog@rivadpm.com> - 2011-08-23 14:59 -0700
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:12 -0400
Re: The Lisp Curse "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:09 -0400
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 Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 11:41 -0500
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 17:11 +0000
Re: The Lisp Curse Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-23 12:27 -0500
Re: The Lisp Curse Brad <hwfwguy@gmail.com> - 2011-08-23 10:07 -0700
Re: The Lisp Curse Pablo Hugo Reda <pabloreda@gmail.com> - 2011-08-23 13:02 -0700
Re: The Lisp Curse vandys@vsta.org - 2011-08-23 20:30 +0000
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: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 13:09 +0000
Re: Hamming numbers Paul Rubin <no.email@nospam.invalid> - 2011-08-23 10:41 -0700
Re: Hamming numbers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-23 17:58 +0000
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 "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-23 20:07 -0400
Re: The Lisp Curse "Elizabeth D. Rather" <erather@forth.com> - 2011-08-23 15:44 -1000
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 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-02 18:37 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iuo6lt$1l9$1@speranza.aioe.org> |
| In reply to | #3701 |
"Elko T" <nono.black.elko@gmail.com> wrote in message news:iulg0a$k6i$1@dont-email.me... > > No. *Your* new post is totally erroneous. Wrong. It's not. There is one mistake, due to you... > Have you ever > programmed an Intel CPU in assembly? > Yes, frequently, albeit I prefer C and use it much more often. > You don't appear to know what its > instructions do; for example you appear to think > that REPNZ MOVSB > repeats until a zero string byte is encountered. > *YOU* wrote "REPNZ MOVSB". Take responsibility for your error: incorrect pairing of repeat prefix and instruction. A failure to catch your mistake or trust that you got something correct was my mistake. REPNZ MOVSB wasn't. Yes, I assumed you got the correct combination before I posted, but like everything else in that post, that was wrong too. So, I explained what each of those meant - together. How is that my error? REPNZ means what I said. MOVSB means what I said. Together, it means what I said. Do they work together? Yes. Do they work that way together? Probably not... REPNZ and MOVSB will probably work as REP MOVSB, i.e., c-string only. MS uses incorrect repeat prefix pairings in a number of places their code. Some of their bootloader code is the most well known example. This doesn't change the flaws in your argument regarding c-strings being better suited to assembly versus z-strings. > All the rest of your arguments are like that - either in error, or > twisting the truth and making nonsensical assumptions. Wrong. There is nothing twisted. It's accurate and correct. The only thing that isn't is your mistakes and things derived from them... > You have been > repeatedly shown wrong By whom? When? Not by you... All of your claims were incorrect. I've explained *repeatedly* why you're wrong. > by my post Your post was completely wrong. I showed you where and told you why. What is it that you don't understand? Comprehension, or lack of, real or feigned, seems to be an issue with you. > and by all the people who > answered you the previous time. I reread the thread that I posted links to after your BS claims that I was thoroughly refuted somewhere. I don't see where anyone demonstrated anything incorrect about what I said. > You obviously refuse to learn from your mistakes; so be it. One can't > teach the unteachables. Cute! Recycling my statements about you: "... You used flawed logic. You're beyond my help." It's there. Go back and reread it. Since you didn't realize it, I'll state it very clearly. I'm not the one being taught. That's as politely as I can state the issue. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | kenney@cix.compulink.co.uk |
|---|---|
| Date | 2011-07-01 06:07 -0500 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <KYmdna1xoM0dN5DTnZ2dnUVZ7v2dnZ2d@giganews.com> |
| In reply to | #3680 |
In article <iuj34p$4gt$1@dont-email.me>, nono.black.elko@gmail.com (Elko T) wrote: > Still waiting for just one redeeming quality of z-strings. ;) There must be some redeeming features as Delphi started with counted strings and now provides both. The main problem with counted strings is the length limit. Extracting sub strings and parsing is fine but when appending it is fairly easy to get a string that is to long to fit in. There is also a possible problem with OS that expand relative paths to absolute paths and return something that is too long to fit. I don't know where counted strings originated but I remember using the Microsoft Basic string functions, which by the way used a separate string space at top of memory, a 255 character limit could bite back. Ken Young
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-01 16:00 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iul92l$mfn$1@speranza.aioe.org> |
| In reply to | #3683 |
<kenney@cix.compulink.co.uk> wrote in message news:KYmdna1xoM0dN5DTnZ2dnUVZ7v2dnZ2d@giganews.com... > > There must be some redeeming features as Delphi started with > counted strings and now provides both. > Delphi most likely provides both since the host OS library is likely in C. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-07-01 14:06 +0000 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <2011Jul1.160645@mips.complang.tuwien.ac.at> |
| In reply to | #3680 |
Elko T <nono.black.elko@gmail.com> writes:
> I see. As you say in one of the old posts that you kindly provided,
>too much C, indeed. In short, all your assertions, both pro
>null-terminated/NUL-terminated (z-strings) and against counted strings
>(c-strings), are mostly wrong.
You make very good arguments for the addr u representation of strings
(and I agree with them). The only problem is that you call this
representation "counted strings", which are commonly understood to be
strings preceded with a count byte and represented only by the address
of the count byte. E.g., from the Forth-94 document:
|counted string: A data structure consisting of one character
| containing a length followed by zero or more contiguous data
| characters. Normally, counted strings contain text.
And calling counted or addr u strings c-strings is confusing because
it makes me think of C strings, which are zero-terminated.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-07-01 14:57 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iul5a9$b2o$1@dont-email.me> |
| In reply to | #3690 |
Anton Ertl wrote: > Elko T <nono.black.elko@gmail.com> writes: >> I see. As you say in one of the old posts that you kindly provided, >> too much C, indeed. In short, all your assertions, both pro >> null-terminated/NUL-terminated (z-strings) and against counted strings >> (c-strings), are mostly wrong. > > You make very good arguments for the addr u representation of strings > (and I agree with them). The only problem is that you call this > representation "counted strings", which are commonly understood to be > strings preceded with a count byte and represented only by the address > of the count byte. E.g., from the Forth-94 document: > > |counted string: A data structure consisting of one character > | containing a length followed by zero or more contiguous data > | characters. Normally, counted strings contain text. > > And calling counted or addr u strings c-strings is confusing because > it makes me think of C strings, which are zero-terminated. Indeed, I should have used better terminology, mea culpa. You understood me perfectly, however - I'm not talking about any particular implementation of counted strings - be it the Forth character "counted string", or the stack-contained "addr u" strings. I'm talking about the situation where each string "object" is characterized by its address and length, which exist as metadata outside of the string, and describe it. -- No, no, you can't e-mail me with the nono.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2011-07-02 16:55 +0000 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <2011Jul2.185555@mips.complang.tuwien.ac.at> |
| In reply to | #3696 |
Elko T <nono.black.elko@gmail.com> writes:
>Anton Ertl wrote:
> Indeed, I should have used better terminology, mea culpa. You
>understood me perfectly, however
Yes, but I already knew all these things, so since some of the things
you wrote did not make sense when applying the usual meaning of
"counted strings", I read the whole length of your posting carefully
and found out that it was about addr u strings.
But I did not benefit from your posting, since I knew these things
already. Somebody who might have benefitted from it if you had used
better terminology probably found it confusing or was mislead by it.
> - I'm not talking about any
>particular implementation of counted strings - be it the Forth
>character "counted string", or the stack-contained "addr u" strings.
>I'm talking about the situation where each string "object" is
>characterized by its address and length, which exist as metadata
>outside of the string, and describe it.
But that's not the case for counted strings. There the length
metadata is part of the pointed-to data structure, and therefore
certain advantages of addr u strings are not shared by counted
strings, e.g. creating a substring is not as simple for counted
strings as you describe, whereas it is as simple for addr u strings.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-01 16:04 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iul99n$n0m$1@speranza.aioe.org> |
| In reply to | #3680 |
"Elko T" <nono.black.elko@gmail.com> wrote in message news:iuj34p$4gt$1@dont-email.me... Who are you talking to? I don't see the headers for the prior conversation. It should be here. Your comments should be interspersed between those of whom you are replying. You're posting to Usenet... > Let's start with efficiency. I claim, that without exception, *any* > operation on counted strings is more efficient than when the length is > unknown a priori and has to be determined from the contents. True, but irrelevant. If the length was needed for operations with z-strings (your terminology), I'd agree with you that c-strings (your terminology) would be faster than terminated strings. But, as I stated, the length is almost never needed with z-string operations. So, there is no advantage to having the count or string's length with z-strings. > outputting: z-strings need a program loop that examines > each character in turn, always. outputing c-strings needs a program loop that examines the count for each loop, always ... Is there point to this? > Depending on how output is implemented in > the particular environment, with c-strings it can be a single > machine language instruction - REPNZ MOVSB, Did you *ACTUALLY* use "REPNZ MOVSB" as proof that c-strings are an improvement over z-strings? With me...? Am I stupid? Wait... Are you stupid? You understand that REPNZ repeats while there is no zero byte, yes? "REPeat (while) Not Zero MOVe String Byte" There's no count involved. Where's the c-string? I.e., it's designed for outputting z-strings... WTF? Wow, you must've gotten seriously confused in your arguments somewhere... It's best to delete such posts rather than send them. Start over, rewrite, it'll come out much better. Trust me. > [...] in the > cases where the OS expects character by character calls, it is still > cheaper to do the loop using a counting instruction like LOOPNZ or > DJNZ, rather than explicitly reading *and* testing every byte. > Dude... JNZ is not a counting instruction (z-string). JCX is a counting instruction (c-string). LOOPNZ is not a purely counting instruction (z-string & c-string). LOOP is a counting instruction (c-string). > - copying: even worse; mostly single machine language instructions for > c-strings, Uh, you clearly misunderstand something, at least for x86... > Add to that the fact that if you > need to allocate the memory for the copy of the string, you need to > read the string all over *twice* - the first time to count to see how > much memory to allocate, and the second time to do the actual copy. > That depends on the copy routine implemented. If a block was previously allocated and known to be sufficiently large which holds for many situations, then that claim isn't true. > - concatenation: same thing. If you know the lengths beforehand, you > can allocate the total first, and then do the efficient moves (or > resize the first string if appending in place, etc.) With z-strings, > you need to scan through at least one of them twice, and through both > of them once. In contrast, with c-strings, if appending in place, you > don't need to touch the first string at all, just copy the second. > Ditto. > With z-strings, you need to scan the source string at least once, no > matter what the operation is, to make sure that the desired substring > is inside the source string's length; You have to do that with c-strings also. How do you locate the substring for either c-strings or z-strings without scanning the original string? That make no sense whatsoever. > - parsing: with z-strings, you need two comparisons - is the byte 0, > is it what we want. In c-strings, we setup the loop parameters by > string length, and make just one comparison inside, leaving the loop > when done. You have to do two comparisons with c-strings also: "is it what we want" and has the counter reached it's terminating value. > Second, let's look at the "errors" of the counted strings. They are > mostly of your imagining. How can it happen that the count is wrong? How does the count get set? Just as someone or something must set the terminator for z-strings, someone or something must get and set an accurate count for c-strings. When something goes wrong, you've got problems. C-strings count errors have more problems. > Maybe if *you* program it, but not in a program by anybody who > routinely uses counted strings, especially a Forther. > Concatenation - > just add the lengths, store the result. Oh, so z-strings via your prior statements must allocate memory but c-strings don't need to? You can just store the results? Your argument is flawed. > Substring - same thing; > subtract, store. If the initial counts are correct, all string > operations will trivially yield correct results. Oh, so z-strings via your prior statements must allocate memory but c-strings don't need to? You can just store the results? Your argument is flawed. When things are done correctly, z-strings work well too. The problems you point out about z-strings are when things do not work well. > Contrary to your > absurd statement in the last of the links you provided, when a > c-string is being modified, one does *not* need to re-count. Why? The string is of a different length. I hope you recounted. > The new > size is trivially calculated from the old. You are under the mistaken > impression that the string data is somehow manipulated in isolation > from the length, No, I'm not. I pointed out what happens in erroneous situations. When you point out flaws in z-strings, you'll point out the error condition: that things go wrong with z-strings when they do not have a terminator. Well, bad things happen with counted string too when the count is not correct. > [..] while in fact they form a logical tuple (address > count), and any correct program manipulates them that way. Just as any correct program using z-strings has no z-strings without a terminator... Using your argumentative logic, z-strings are perfect. They have no problems. > For ex, > when editing in a line buffer, you increase the count when inserting a > character, decrease the count when deleting, don't change it when > overwriting. There's no need to re-scan or re-count. > Increasing or decreasing the count is not a "re-count"? Word games... As for z-strings, as long as the buffer is large enough - I'm assuming it is since you didn't allocate any space for your example, then you only need to move characters, just as needed for c-strings, when inserting or deleting characters. I.e., there is no need to update a count or a termintor. It's less work. > Is it, or isn't it true, that when accepting a > stream of data, where the size of the data is determined by its > contents, one can overflow any pre-allocated buffer? Yes, and c-strings have this issue too. What's your point? > All that > needed not be done, had it started with proper counted strings, where > all operations are correct from the get-go, and screwups of that > nature can't happen. > Wrong! > Fourth, metadata. It's part of a bigger problem, actually. Even the > counted strings where the count is adjacent to the beginning of the > string are flawed, but less so than the z-strings. Ideally, the > address/count pair should be in a separate location from the string > itself, in a separately allocated memory area. The reason is that if a > misbehaving program overwrites it, the size is lost. z-strings don't have that problem... There's no count. So, the count cannot be overwritten. The address of a z-string, depending on what the compiler did with it, may or may not be overwritten. The z-string may or may not be overwritten, depending on how it was declared in C or what operating system privileges are available. Strings are not always writable. The length of a z-string is determined by the terminator. If the terminator is overwritten, you'll have a problem. If that terminator is more than the allocation, then there is a bug. If the count for a c-string is more than the allocation, then there is a bug too. But, z-strings have fewer side-effects and serious problems. > This is > especially troublesome for other data structures. For example arrays, > if they store their sizes inside themselves. Or memory managers, that > store the size and owner of the allocated memory segment at the > beginning of the chunk, at a negative offset to the address they > return to the requesting application. > It seems the systems you're familiar all use writable strings. Some languages and operating systems restrict that. > Fifth, one more flaw of z-strings that I just remembered - they > can't contain the NUL character. So? It's not a z-string then is it? It's just raw byte data. C handles that without any problems at all. The raw data is an "array" of small integers: characters specifically. Yes, C handles the NUL character by using characters. Is your mind "blown" now? C's functions determine if the data is a z-string or not. strxxxx() recognize NUL. memxxx() do not recognize NUL. > Rod Pemberton wrote: > > "Elko T" <nono.black.elko@gmail.com> wrote in message > > news:iuglrm$96e$1@dont-email.me... > >> Rod Pemberton wrote: > >>> "Nomen Nescio" <nobody@dizum.com> wrote in message > >>> These go at the top. They are supposed to stay there. This goes afterwards with your comments inserted. The quantity of > indicate who said what to indicate to what you are replying. > >>>> One main advantage to PL/I over C is how PL/I handles strings, > >>>> but since I believe you are a fan of null terminated strings you > >>>> probably won't agree. > >>> I don't agree. I lived through the "counted strings" era and saw > >>> the numerous issues with them. Nul-terminated strings put an > >>> end to those problems, many of which I mentioned here recently. > > > > Actually, it seems, NN said "null terminated strings". I mistook that for > > NUL-terminated strings. "Null terminated strings" are something else > > entirely in the C context, nowadays. Null in C is not a character value > > anymore. It was prior to ANSI standards. Modern C's null is a pointer. > > So, no I don't like null terminated strings. > > > >> I have no issue with most of what you say, but this statement is > >> truly bizarre. > >> > > > > [SNIP] > > Down here, you delete the signature of the person replying, when you reply. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-02 11:26 -0700 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <a964f93e-e2c5-4d35-a020-e66cd3eee4fe@j28g2000vbp.googlegroups.com> |
| In reply to | #3700 |
On Jul 1, 9:04 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Elko T" <nono.black.e...@gmail.com> wrote in message > > news:iuj34p$4gt$1@dont-email.me... > > Who are you talking to? I don't see the headers for the prior conversation. > It should be here. Your comments should be interspersed between those of > whom you are replying. You're posting to Usenet... > > > Let's start with efficiency. I claim, that without exception, *any* > > operation on counted strings is more efficient than when the length is > > unknown a priori and has to be determined from the contents. > > True, but irrelevant. If the length was needed for operations with > z-strings (your terminology), I'd agree with you that c-strings (your > terminology) would be faster than terminated strings. But, as I stated, the > length is almost never needed with z-string operations. So, there is no > advantage to having the count or string's length with z-strings. > > > outputting: z-strings need a program loop that examines > > each character in turn, always. > > outputing c-strings needs a program loop that examines the count for each > loop, always ... Is there point to this? > > > Depending on how output is implemented in > > the particular environment, with c-strings it can be a single > > machine language instruction - REPNZ MOVSB, > > Did you *ACTUALLY* use "REPNZ MOVSB" as proof that c-strings are an > improvement over z-strings? With me...? Am I stupid? Wait... Are you > stupid? You understand that REPNZ repeats while there is no zero byte, yes? > "REPeat (while) Not Zero MOVe String Byte" There's no count involved. > Where's the c-string? I.e., it's designed for outputting z-strings... WTF? > Wow, you must've gotten seriously confused in your arguments somewhere... > It's best to delete such posts rather than send them. Start over, rewrite, > it'll come out much better. Trust me. "REPNE and REPNZ ... repeat their associated string instruction the number of times specified in the counter register (rCX). The repetition terminates when the value in rCX reaches 0 or when the zero flag (ZF) is set to 1. The REPNE and REPNZ prefixes can be used with the CMPS, CMPSB, CMPSD, CMPSW, SCAS, SCASB, SCASD, and SCASW instructions." "REPE and REPZ ... repeat their associated string instruction the number of times specified in the counter register (rCX). The repetition terminates when the value in rCX reaches 0 or when the zero flag (ZF) is cleared to 0. The REPE and REPZ prefixes can be used with the CMPS, CMPSB, CMPSD, CMPSW, SCAS, SCASB, SCASD, and SCASW instructions." "The REP prefix repeats its associated string instruction the number of times specified in the counter register (rCX). It terminates the repetition when the value in rCX reaches 0. The prefix can be used with the INS, LODS, MOVS, OUTS, and STOS instructions." AMD64 Architecture Programmer’s Manual Vol 3, Pub# 24594 3.15 November 2009 MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ prefix. Only REP is permitted, which is entirely dependent on a count in rCX, and does not inspect the bytes/words/dwords moved. > > > [...] in the > > cases where the OS expects character by character calls, it is still > > cheaper to do the loop using a counting instruction like LOOPNZ or > > DJNZ, rather than explicitly reading *and* testing every byte. > > Dude... > > JNZ is not a counting instruction (z-string). JCX is a counting instruction > (c-string). LOOPNZ is not a purely counting instruction (z-string & > c-string). LOOP is a counting instruction (c-string). > All instructions that branch based on a condition code require it to be set by something; an arithmetic or comparison operation normally. In the case of a null-terminated string (a z-string in the terminology here), such a compare will read and test every byte.
[toc] | [prev] | [next] | [standalone]
| From | coos haak <chforth@hccnet.nl> |
|---|---|
| Date | 2011-07-02 22:10 +0200 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <8m6wf1ymssdd$.l59sdsigf608.dlg@40tude.net> |
| In reply to | #3718 |
Op Sat, 2 Jul 2011 11:26:25 -0700 (PDT) schreef Alex McDonald: <snip> > MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ > prefix. Only REP is permitted, which is entirely dependent on a count > in rCX, and does not inspect the bytes/words/dwords moved. > If I write REP MOVS or REPZ MOVS the same opcodes are assembled ;-) By some strange decision of Intel, there are only two repeat prefixes REPZ/REPE or REP (F3) and the other is REPNZ or REPNE (F2). -- Coos CHForth, 16 bit DOS applications http://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-02 14:36 -0700 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <bc123b56-3ab8-48ca-b28b-459e084a9081@j15g2000yqf.googlegroups.com> |
| In reply to | #3719 |
On Jul 2, 9:10 pm, coos haak <chfo...@hccnet.nl> wrote: > Op Sat, 2 Jul 2011 11:26:25 -0700 (PDT) schreef Alex McDonald: > > <snip>> MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ > > prefix. Only REP is permitted, which is entirely dependent on a count > > in rCX, and does not inspect the bytes/words/dwords moved. > > If I write REP MOVS or REPZ MOVS the same opcodes are assembled ;-) > > By some strange decision of Intel, there are only two repeat prefixes > REPZ/REPE or REP (F3) and the other is REPNZ or REPNE (F2). Yes. REPNZ (F2) or REPZ (F3) MOVSx means REP as no condition code is set by MOVSx; the effect is REP regardless. Its also used in SIMD instructions, where F2 and F3h modify the opcode, rather than do a REP. > > -- > Coos > > CHForth, 16 bit DOS applicationshttp://home.hccnet.nl/j.j.haak/forth.html
[toc] | [prev] | [next] | [standalone]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-07-02 21:36 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iuoh3n$neq$1@dont-email.me> |
| In reply to | #3722 |
Alex McDonald wrote: > On Jul 2, 9:10 pm, coos haak <chfo...@hccnet.nl> wrote: >> Op Sat, 2 Jul 2011 11:26:25 -0700 (PDT) schreef Alex McDonald: >> >> <snip>> MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ >>> prefix. Only REP is permitted, which is entirely dependent on a count >>> in rCX, and does not inspect the bytes/words/dwords moved. >> If I write REP MOVS or REPZ MOVS the same opcodes are assembled ;-) >> >> By some strange decision of Intel, there are only two repeat prefixes >> REPZ/REPE or REP (F3) and the other is REPNZ or REPNE (F2). > > Yes. REPNZ (F2) or REPZ (F3) MOVSx means REP as no condition code is > set by MOVSx; the effect is REP regardless. Its also used in SIMD > instructions, where F2 and F3h modify the opcode, rather than do a > REP. Indeed. All three forms (REP/REPZ/REPNZ) are supposed to produce the same outcome when assembling, and the two opcodes F2 and F3 are supposed to work the same, on *the non-testing* instructions. Interestingly, however, Intel always gives F3 for REP in its docs, while an old Turbo Assembler manual I have, gives F2 for the LODS instructions, and F3 for the rest. -- No, no, you can't e-mail me with the nono.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Date | 2011-07-02 18:25 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iuo5ug$vpn$1@speranza.aioe.org> |
| In reply to | #3718 |
"Alex McDonald" <blog@rivadpm.com> wrote in message news:a964f93e-e2c5-4d35-a020-e66cd3eee4fe@j28g2000vbp.googlegroups.com... > > "REPNE and REPNZ [...] > "REPE and REPZ [...] ... > MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ > prefix. Only REP is permitted, which is entirely dependent on a count > in rCX, and does not inspect the bytes/words/dwords moved. False. It's not the intended prefix. Microsoft does such stuff in their code. There are a number of such examples. The most well known one is in their boot loader code. I think that's still in-use to this day. Does REPNE with an incorrect instruction work as a REP or REPNE? I don't know. I would assume REP. > All instructions that branch based on a condition code require it to > be set by something; an arithmetic or comparison operation normally. > In the case of a null-terminated string (a z-string in the terminology > here), such a compare will read and test every byte. Yes, and a count will compared for each and every byte to for instructions suited for c-strings... I've already stated this. Elko T stated that this is some sort of advantage for c-strings over z-strings. It's not. Both have the same issues in regards to looping. RP
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-03 10:53 -0700 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <fb70dda0-1e7b-4af8-80b6-92030242ec01@q5g2000yqj.googlegroups.com> |
| In reply to | #3723 |
On Jul 2, 11:25 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm> wrote: > "Alex McDonald" <b...@rivadpm.com> wrote in message > > news:a964f93e-e2c5-4d35-a020-e66cd3eee4fe@j28g2000vbp.googlegroups.com... > > > "REPNE and REPNZ [...] > > "REPE and REPZ [...] > > ... > > > MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ > > prefix. Only REP is permitted, which is entirely dependent on a count > > in rCX, and does not inspect the bytes/words/dwords moved. > > False. It's not the intended prefix. Microsoft does such stuff in their > code. There are a number of such examples. The most well known one is in > their boot loader code. I think that's still in-use to this day. Does > REPNE with an incorrect instruction work as a REP or REPNE? > I don't know. I would assume REP. I misused the word "permitted"; All F2/F3 REPs prefixing MOVSx and any opcode that doesn't set the condition code are treated by the processor as REP. > > > All instructions that branch based on a condition code require it to > > be set by something; an arithmetic or comparison operation normally. > > In the case of a null-terminated string (a z-string in the terminology > > here), such a compare will read and test every byte. > > Yes, and a count will compared for each and every byte to for instructions > suited for c-strings... I've already stated this. Elko T stated that this > is some sort of advantage for c-strings over z-strings. It's not. Both > have the same issues in regards to looping. But if for example SIMD instructions are used, then no testing of condition codes is required if you know the length on advance. I can't understand you're passion for nul-terminated strings. > > RP
[toc] | [prev] | [next] | [standalone]
| From | Elko T <nono.black.elko@gmail.com> |
|---|---|
| Date | 2011-07-04 23:41 -0400 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <iuu16f$mji$1@dont-email.me> |
| In reply to | #3718 |
Alex McDonald wrote: > > AMD64 Architecture Programmer’s Manual Vol 3, Pub# 24594 3.15 November > 2009 > > MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ > prefix. Only REP is permitted, which is entirely dependent on a count > in rCX, and does not inspect the bytes/words/dwords moved. Hehe, Alex, check the source code for CMOVE in Win32Forth. :) -- No, no, you can't e-mail me with the nono.
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2011-07-05 01:02 -0700 |
| Subject | Re: Counted vs. terminated strings (Re: The Lisp Curse) |
| Message-ID | <808af979-9337-4889-9343-229f7f7118ba@b21g2000yqc.googlegroups.com> |
| In reply to | #3792 |
On Jul 5, 4:41 am, Elko T <nono.black.e...@gmail.com> wrote: > Alex McDonald wrote: > > > AMD64 Architecture Programmer’s Manual Vol 3, Pub# 24594 3.15 November > > 2009 > > > MOVSx instructions are not permitted with a REPE/REPNE/REPZ/REPNZ > > prefix. Only REP is permitted, which is entirely dependent on a count > > in rCX, and does not inspect the bytes/words/dwords moved. > > Hehe, Alex, check the source code for CMOVE in Win32Forth. :) > > -- > No, no, you can't e-mail me with the nono. My personal version of CMOVE uses REP. The existing assembler is deficient and allows such a thing. I'm rewriting the assembler at the moment; I found it extremely difficult making minor changes to the existing code without having it break. There's a simplified version that does 32bit addressing only out on http://tech.groups.yahoo.com/group/win32forth/files/Users/Alex/asm.zip.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2011-07-02 22:46 +0200 |
| Message-ID | <7b1b5a489c11af47a5f0eac9e158f1a8@dizum.com> |
| In reply to | #3670 |
> Counted strings can result in erroneous code too. The count can be wrong > for the string. That can lead to a number of problems: storage that's not > free'd, storage that shouldn't have been free'd, wrong text output, etc. > String storage that's not free'd because of an incorrect count value is a > memory leak. Storage that shouldn't have been free'd can lead to data > corruption or program crashes. If the count is short, the text output is > truncated. What if that happens on an choice-based input prompt? If the > count is too long, it can emit unintentional text characters, such as > control characters which could shift the character set on terminals and > terminal emulators. Some control sequences may even block keyboard input. all those errors are bugs in compilers which are nowadays unusual and anyway are all fixed in one place instead of the uncountable buffer overflows coded by incompetent coders. I trust somebody putting out a compiler (ok not gcc, but a normal company) to do a better job than the average code butcher or gpl groupie. > How so? The string length is almost never needed. Loop until terminator > found. That's good for copying, printing, moving strings. Search for a > character, insert NUL. That's good for substrings etc. When the string > length is needed, the string should be terminated and can be counted. If > you want to be safer, without using safe string functions, you can > automatically insert a NUL in the last character position of the string. > You know the string length. It's in the declaration or malloc() call. That's in your architecture in your OS. Byte by byte moves are horribly inefficient on the platform I work on. We have instructions to move up to 256 bytes with one opcode, up to 4096K page aligned bytes with one opcode, and a microprogrammed long move of any practical length (I think it's 2**24) but I can't remember at the moment. Same thing for compares. PL/I knows how to move strings efficiently because of having the length of source and target at all times. Avoids those embarrassing printf and deadly scanf type errors too. > How do you explain integers, floats, structs, unions, and the count for > counted strings, etc? Integers and floats have no "metadata" at runtime. I don't necessarily agree with what he wrote but to answer you, those other objects also have either architecturally defined, system defined, or programmer defined lengths that *are* known.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-07-18 01:25 -0400 |
| Message-ID | <jng727di48hb1h89v0dup89oknjlo94tac@4ax.com> |
| In reply to | #3670 |
On Thu, 30 Jun 2011 10:07:29 -0400, "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote: <snip: counted versus (null)terminated> > Actually, it seems, NN said "null terminated strings". I mistook that for > NUL-terminated strings. "Null terminated strings" are something else > entirely in the C context, nowadays. Null in C is not a character value > anymore. It was prior to ANSI standards. Modern C's null is a pointer. > So, no I don't like null terminated strings. > That's not a change. C since its beginning had null pointers (although only with porting and then standardization was it clear that null pointers must be typed, because the representation of different pointer types can vary) and also a null character. There is a standard macro NULL which provides a null pointer, but so does a literal 0 or (type*)0 or with C89 (void*)0. The character literal '\0' provides a null character, but so does a literal 0. The fact that null pointers and null characters can both be expressed as 0 does not and never did make them identical. > > Zero-terminated strings are the biggest drawback > > Zero-terminated might be perfectly valid description for NUL-terminated > strings for some languages. FYI, that's not so for C. > > In C, strings are not zero terminated. In C, zero is a value for an integer > or character. In C, strings are "all bits zero" terminated. This is a > "byte" in C, or multiple bytes, and not a character. Simply put, a C "byte" > is an address unit(s) as large, or larger, than a character's size in bits. A C 'byte' must be addressable (yes) and at least 8 bits and large enough to contain a character (yes) from a set whose minimum is defined by the standard and effectively requires at least 7 bits. A (normal/classic) string, that is a string of 'char' elements, each of which is exactly one byte, is terminated by exactly one byte of zero. Even if the implementation uses multibyte encodings for some characters, with UTF-8 as a prominent example, a single byte=char of 0 must always be a terminator. A 'wide' string, whose elements are wchar_t, is terminated by exactly one wchar_t of 0. wchar_t typically is 16 bits, which is 2 bytes on machines with 8-bit bytes -- which is nearly all, but the standard doesn't require (either of) these. A zero value of type char=byte or wchar_t is a zero. Perhaps in some sense this isn't a NUL character, although it converts to or from and compares equal to NUL, but it is definitely a zero, just like an int 0 is a zero and a float 0.0f is a zero. It is sometimes quite reasonable to have a sequence of int's terminated by an int 0, which _is_ a zero-terminated sequence or zero-delimited array, although not one built into the compiler like strings of char terminated by char 0. > If strings were zero terminated in C, an ASCII or EBCDIC NUL would suffice > to terminate the string. Syntactically, that's how you terminate strings in > C, you use a NUL character: '\0'. However, to comply with the C > specifications, C must clear the bits for the entire string terminator > "byte" with '\0', not just the bits used for the character. This is an > issue if C bytes and characters are of different sizes in bits. > True for '\0' because *every* character in C fills a byte. In char c; c = 'X'; 'X' is actually a value of at least a 16-bits (character literals have type int in C, and int must be at least 16-bits) and the store to c always stores all bits of that byte, even if 'X' would fit in 7 bits. memcpy memcmp etc. could not have worked otherwise, and from very early K&R1 until C89 those routines were defined in terms of char. (C89 made the _pointers_ void* for convenience, but continued to define the targets as char, specifically unsigned char.) For larger types like 'short' and 'int' C>=89 confirms storage can include padding bits, but not 'unsigned char', and practice has never allowed it for any 'char' type because many C programs have always assumed that accesses through any 'flavor' of char pointer can read and write all bits of memory (that can be read/written at all). <snip substantive points about counted versus terminated>
[toc] | [prev] | [next] | [standalone]
| From | Chris Hinsley <chris.hinsley@gmail.com> |
|---|---|
| Date | 2011-06-30 14:44 +0100 |
| Message-ID | <2011063014441245149-chrishinsley@gmailcom> |
| In reply to | #3657 |
> Has any operating system written in assembly been ported to > another platform? (No, or very few...) Taos/Intent. Ran on around 30 different CPU's, numorous hosted enviroments, and 10's of different customer platforms. But yes, it's not a common thing. And no doubt, people would argue that VP wasn't assembler, it was a compiled intermediate code you could hand code at the source level like an assembler. But I couldn't let your comment just go by. :) Chris
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markrobertwills@yahoo.co.uk> |
|---|---|
| Date | 2011-06-30 23:24 +0100 |
| Message-ID | <BYCdnW8bwO0papHTnZ2dnUVZ8tqdnZ2d@bt.com> |
| In reply to | #3669 |
On 30/06/2011 14:44, Chris Hinsley wrote: >> Has any operating system written in assembly been ported to >> another platform? (No, or very few...) > > Taos/Intent. Ran on around 30 different CPU's, numorous hosted > enviroments, and 10's of different customer platforms. > > But yes, it's not a common thing. And no doubt, people would argue that > VP wasn't assembler, it was a compiled intermediate code you could hand > code at the source level like an assembler. But I couldn't let your > comment just go by. :) > > Chris > Hmmmm.... Taos.... Swoon... ;-)
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201107.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-07-03 12:04 +0200 |
| Message-ID | <2746c0939d1a238ee58384acafc1b122@msgid.frell.theremailer.net> |
| In reply to | #3657 |
> > If you look at the IBM mainframe the operating system is written in > > assembler. > > Has any operating system written in assembly been ported to > another platform? (No, or very few...) Not important, especially in the case I am talking about, since the hardware and software were designed for each other. It doesn't make sense to port the OS and they have never needed to because the company that puts out the OS also designs and builds the hardware. You can be portable or optimized, but not both. IBM chose to optimize as much as possible and they did it by controlling the hardware and software as a unified package instead of making it run everywhere badly. > Has any operating system written in C been ported to > another platform? (Yes, many...) Many bad ones. Again, so what? > Assembly code "dies". It's affixed to the specific processor in use. I > learned that decades ago. Well I learned decades ago that the same assembler code that worked in 1964 still works today. That's almost 50 years. How much longer should the code live before your concern becomes invalid? > HLL code survives. Really? What about the guy who posted recently about his production Modula 2 code breaking and having no way to fix it? What about all the incompatbilities introduced by Intel and MS so that old code doesn't work anymore on those platforms? DOS code won't run on anything from NT and on...etc. Bottom line is more HLL code has been thrown away than assembler! > > All the header files and system calls are in assembler. If you > > want to use C on a mainframe you cannot physically write system > > code. At all > > "At all" is a bit of an extreme claim. No, it's simple fact. You cannot write system code in MVS in any language but assembler. Even if you could get mappings for system control blocks in other languages the code would quickly fall over because it doesn't have control over facilities that system code needs. > The GCCMVS project (Paul Edwards) ported GCC to MVS. I don't know much > about MVS, but I assume it was written in assembly. Before you said assembly was bad because it doesn't go cross platform but here you're giving an example of the most highly ported product out there, probably, and it's written in assembly at least enough of it to be able to be self bootstrapping or they would have needed to use an IBM licensed compiler to compile gcc which I'm sure Stallman and his groupies would never tolerate since IBM is evil and charges money and does so much closed source code. I looked into this the last time we talked about it. You don't understand what gccmvs is and what it's good for (not much) because you don't work in that environment. If you did you would realize how limited it is. First of all there is a much more capable C compiler out there from IBM with real libraries that give an MVS programmer the tools he needs to write useful application code and access a reasonable range of application facilities. Not nearly as much as COBOL or PL/I, but about as good as Java on MVS. gccmvs is missing basic things required for applications and doesn't have access to virtually anything a programmer needs in that environment, it's a special purpose tool, not a general purpose one. MVS is not POSIX. In Linux on MVS hardware gccmvs could be worthwhile, but I think regular gcc is already ported there. That brings us to the reason for gccmvs. The mainframe is not used by hobbyists because they're too expensive and the OS and software are expensive and no production shop uses GCCMVS, it's basically something Paul needed to do his updates to the public domain OS IBM from 1974. gccmvs has no system interface (it has very limited support for application interface) and it is not system code. They had to write wrappers to make it appear POSIX-like but it doesn't use IBM's POSIX facilities, because they were not available in 1974 and he needs his code to work backwards. The OS he is patching also doesn't have the underlying OS that does have POSIX support. It's basically a way to make a mainframe run C like on a PC, with some minor local modifications. If you are happy with printf etc. it might be enough for you. You cannot write system code in it, you can't do basic file system operations that the IBM C compiler supports, etc. It's a special purpose tool for hobbyists and that's it. Even IBM's C compiler has no support for writing systems software, and not their Metal C either. > So, it probably did what you claim cannot be done "at all". No, it didn't. Not even close. It just provides application wrappers to application level services. It does not go anywhere near systems services. Paul himself clearly says that in various yahoo groups posts I found. Windows and UNIX are so different from MVS and magnitudes less capable, so I'm not surprised there is no reference frame here for discussion. However most of the doc is online, if you have a couple free decades and want to see how it should be done, you can look! > DOS is also written in assembly. DJGPP (GCC port) for DOS does just what > you claim cannot be done. What does DOS do that I claim cannot be done? I have no idea what you are talking about. > Line-oriented BASIC was the only place GOTOs are needed. No. FORTRAN and COBOL also need them to have the code generated in an efficient way and used properly they increase readability dramatically. > As for C, there is no need for them whatsoever. http://www.kernel.org/pub/linux/docs/lkml/#s15-5 What you said is not true and goes against the original K&R where they explained when goto is appropriate in C. The Linux kernel developers use gotos heavily in the kernel, see above link. Now I realize goto's are almost never appropriate in C but you don't realize they are almost always appropriate in FORTRAN and COBOL. You have to know the language and use it idiomatically instead of trying to make everything a C program because if you do that with other languages the code doesn't look right and performance suffers alot. > There are problems with assembler: the code "dies", Not on the platform and OS I work on. > it's not as easily maintained Depends who you are and what code. I can maintain bad assembler alot better than I can maintain good C. YMMV. > and it's harder to use variables, struct's, etc. Maybe in your assembler(s) but not in ours. The assembler we use was designed for heavy duty use and has tons of features that make it as capable as any HLL including a native macro language that is almost an HLL itself. > Ada is a US Gov't requirement for some projects. Not for more than a decade. And what does that have to do with what we were discussing? > It's got assembly. It's got a half-dozen assemblers for it. NASM is a > decent assembler for it. yeah but then you still have to deal with Intel's abominable "architecture". The reason MVS is so nice for assembler developers is the OS is written in assembler and all the system interface is in assembler. We don't have to figure out idiotic C calling conventions designed for compiler back ends or look at header files in a foreign language, everything is designed around supporting the assembler programmer. The architecture is elegant, powerful and efficient. No horseshit libraries needed to do things like storage management (can you spell libc boys and girls?), everything is a documented application or system service. It comes with real manuals and real error messages, not stuff like ooops, sorry, etc. > > PL/I avoids the whole issue of buffer overruns on string operations > > since it knows the length of the source and target and will positively > > not blow off the end of a string. > > > > One disadvantage versus many ... Maybe but PL/I application code doesn't crash the system or cause integrity exposures and C code does. Every day of the week. > "... everything has a purpose or place ..." Psychologically, I'd guess your > MBTI type indicates you seek: harmony (NF) ... Ha, no. You missed that one. Assembler, FTW!
[toc] | [prev] | [next] | [standalone]
Page 12 of 17 — ← Prev page 1 … 10 11 [12] 13 14 … 17 Next page →
Back to top | Article view | comp.lang.forth
csiph-web