Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31555 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2014-06-15 07:06 -0700 |
| Last post | 2014-08-12 03:51 -0700 |
| Articles | 20 on this page of 143 — 27 participants |
Back to article view | Back to comp.lang.forth
FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 07:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 08:48 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-15 23:43 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX rickman <gnuarm@gmail.com> - 2014-06-15 19:44 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-16 02:21 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-16 09:26 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-17 04:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX rickman <gnuarm@gmail.com> - 2014-06-15 19:39 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 09:27 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-17 20:12 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 21:15 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-17 22:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 23:11 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-18 16:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-20 05:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-20 14:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-20 17:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-20 17:53 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 10:57 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 13:30 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:58 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 14:22 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-21 20:13 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 21:54 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX bruce.mcfarling@gmail.com - 2014-06-21 22:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-22 05:31 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:04 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 18:02 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-23 02:53 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 20:29 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-22 13:40 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 12:08 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX november.nihal@gmail.com - 2014-06-22 16:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 20:30 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-26 15:17 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-26 15:51 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-26 22:49 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-27 07:32 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-27 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-28 06:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-28 08:07 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-28 08:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-28 07:23 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-28 22:46 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-27 02:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-28 07:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-28 11:23 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-07-28 19:21 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-28 20:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX visualforth@rocketmail.com - 2014-07-29 11:10 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-29 09:45 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 07:44 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-29 17:48 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-29 11:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-07-29 12:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-29 18:36 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 20:38 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-29 21:43 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 23:05 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-30 22:20 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-31 00:19 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-07-30 01:41 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-30 21:42 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-07-31 01:08 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-31 20:25 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-08-01 02:23 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Lars Brinkhoff <lars.spam@nocrew.org> - 2014-08-01 12:54 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-01 19:57 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-02 04:18 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-27 02:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX bruce.mcfarling@gmail.com - 2014-06-21 21:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-21 22:36 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 22:44 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-22 02:26 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:41 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:43 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-22 19:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-24 21:04 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-24 15:21 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:21 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-25 03:16 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 12:08 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 14:08 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 19:13 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:14 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 21:03 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-26 12:13 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-25 16:14 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:27 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:24 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-26 03:27 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:50 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-27 03:13 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-27 12:30 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-06-25 03:46 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-25 16:15 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 13:19 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:52 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-26 10:45 +0400
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-26 09:56 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-26 11:30 +0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:38 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-25 20:49 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:54 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX David Thompson <dave.thompson2@verizon.net> - 2014-07-26 21:53 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <ayrnieu@gmail.com> - 2014-06-22 22:22 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-24 17:05 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-24 20:55 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-24 19:52 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 13:09 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-23 00:17 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-23 00:27 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:45 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:54 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-24 00:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-27 03:33 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 18:20 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-25 18:50 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 20:00 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-25 23:02 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-26 10:28 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-26 07:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-26 07:59 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:33 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:26 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:22 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-18 22:07 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-18 19:28 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-06-18 23:09 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-18 20:02 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-19 18:28 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-17 21:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-06-17 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX jyf <jyf1987@gmail.com> - 2014-06-19 22:13 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-19 22:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX brelliott18@hotmail.com - 2014-08-10 09:15 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-11 14:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-11 23:51 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX brelliott18@hotmail.com - 2014-08-12 03:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-12 03:51 -0700
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-24 15:21 -1000 |
| Message-ID | <rf-dnTsF19mquTfOnZ2dnUVZ_u6dnZ2d@supernews.com> |
| In reply to | #31801 |
On 6/24/14 3:04 PM, Rod Pemberton wrote: > On Sun, 22 Jun 2014 22:57:55 -0400, <hughaguilar96@yahoo.com> wrote: >> On Sunday, June 22, 2014 7:41:58 AM UTC-7, Roger Levy wrote: > >>> 255 chars is surprisingly hard to fill up that often. I haven't needed >>> bigger ones, yet. In other languages, say if you have to load and >>> process a file, you have to put it into a string variable to do >>> anything, but in Forth you can pass around an addr and count to deal >>> with long strings, and process bits and pieces using counted ones, if >>> you need to save anything. I think it's a good system. >> >> The limitation of 255 chars in a string does become a problem sometimes. > > I've already told you and everyone else here the solution to that numerous > times, but I suspect you're not going to like hearing the answer, again: > > NUL-TERMINATED STRINGS > > Implment a strlen() function as a primitive, say (STRLEN) . Rewrite your > inner and outer interpreter etc to use nul-terminated strings. Rewrite > COUNT. I didn't go look this up for you, so for some aspects of what > need to be done, you may need to figure it out for yourself, or ask. > > Change C@ in COUNT to your (STRLEN) primitive: > > : COUNT ( addr -- addr+1 count ) DUP CHAR+ SWAP C@ ; ( ANS core ) > : COUNT ( addr -- addr+1 count ) DUP CHAR+ SWAP (STRLEN) ; ( ANS core ) Most systems that have to cope with host OSs and C already have such functions. Many of us don't like to use them even when they're available because of the requirement for runtime counting, which is a performance drain. Depending on what kind of application you're writing, 255 chars is useful 90+% of the time, and it's easy to add cell-count words for the exceptional cases. And we would never re-define COUNT, because it would break code in existing systems under maintenance. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-25 18:21 -0400 |
| Message-ID | <op.xh0613h46zenlw@localhost> |
| In reply to | #31802 |
On Tue, 24 Jun 2014 21:21:57 -0400, Elizabeth D. Rather <erather@forth.com> wrote: > On 6/24/14 3:04 PM, Rod Pemberton wrote: >> On Sun, 22 Jun 2014 22:57:55 -0400, <hughaguilar96@yahoo.com> wrote: >>> On Sunday, June 22, 2014 7:41:58 AM UTC-7, Roger Levy wrote: > And we would never re-define COUNT, because it would break code in > existing systems under maintenance. > I figured you were going to say that. It's not an issue. C has gone through the same process. It's Forth's time now. Just introduce changes to the language slowly to allow programmers time to fix the code. E.g., C has eliminated implicit int's, added void types, added typedef's, etc. These and other issues require either fixing the code, or adding options to the compiler to select the version of the language. IIRC, Forth had some words to tell the user which version is in use. Just add another to select the wordset. Isn't that already available in Forth? I.e., vocabularies. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-06-25 03:16 -0500 |
| Message-ID | <bZKdnaJwUcPBGDfOnZ2dnUVZ_tWdnZ2d@supernews.com> |
| In reply to | #31801 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > On Sun, 22 Jun 2014 22:57:55 -0400, <hughaguilar96@yahoo.com> wrote: >> On Sunday, June 22, 2014 7:41:58 AM UTC-7, Roger Levy wrote: > >>> 255 chars is surprisingly hard to fill up that often. I haven't needed >>> bigger ones, yet. In other languages, say if you have to load and >>> process a file, you have to put it into a string variable to do >>> anything, but in Forth you can pass around an addr and count to deal >>> with long strings, and process bits and pieces using counted ones, if >>> you need to save anything. I think it's a good system. >> >> The limitation of 255 chars in a string does become a problem sometimes. > > I've already told you and everyone else here the solution to that numerous > times, but I suspect you're not going to like hearing the answer, again: > > NUL-TERMINATED STRINGS That would be a huge backward step. Zero-terminated strings are one of the worst design decisions to afflict C, and more recent languages like C++ and Java have, very sensibly, moved away from them. Forth got this one right. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2014-06-25 12:08 +0300 |
| Message-ID | <loe3i0$2oa$1@dont-email.me> |
| In reply to | #31806 |
On 06/25/2014 11:16 AM, Andrew Haley wrote: > Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >> I've already told you and everyone else here the solution to that numerous >> times, but I suspect you're not going to like hearing the answer, again: >> >> NUL-TERMINATED STRINGS > > That would be a huge backward step. Zero-terminated strings are one > of the worst design decisions to afflict C, and more recent languages > like C++ and Java have, very sensibly, moved away from them. Forth got > this one right. NUL terminated strings are indeed a scourge. But OS libraries often want them. 255 bytes strings are often not long enough. In Reva I had regular and long strings. Regular with 255 byte counts, long with 4-byte counts. Still in the regular Forth paradigm. In my new system strings have long counts, and automatically deal with resizing etc. In both Reva and my new system, strings are *also* NUL terminated, making it always possible to pass a string to a library routine without any issues.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-06-25 14:08 +0000 |
| Message-ID | <2014Jun25.160804@mips.complang.tuwien.ac.at> |
| In reply to | #31809 |
Ron Aaron <rambamist@gmail.com> writes:
>NUL terminated strings are indeed a scourge. But OS libraries often
>want them.
OS library functions like open are relatively easy to handle. The
names live only until the end of the call to the function. So we can
dynamically allocate the strings and know exactly when to free them
(right after the library call). And we allocate them when we pass
them from the Forth world to the C world, i.e., at the start of the
call, with an explicit conversion word.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2014-06-25 19:13 +0300 |
| Message-ID | <loeseh$ofe$1@dont-email.me> |
| In reply to | #31817 |
On 06/25/2014 05:08 PM, Anton Ertl wrote: > OS library functions like open are relatively easy to handle. The > names live only until the end of the call to the function. So we can > dynamically allocate the strings and know exactly when to free them > (right after the library call). And we allocate them when we pass > them from the Forth world to the C world, i.e., at the start of the > call, with an explicit conversion word. But it is easier and faster and uses less memory to simply have the string already prepared to be sent out, no? In Reva (et al) there's no need to allocate/copy/deallocate the string specifically in order to send it over the FFI. Besides those advantages, it is also one less thing the programmer needs to consider, one place fewer for a bug to occur. And it only costs one byte extra per string. Ron
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-06-25 17:14 +0000 |
| Message-ID | <2014Jun25.191458@mips.complang.tuwien.ac.at> |
| In reply to | #31821 |
Ron Aaron <rambamist@gmail.com> writes:
>
>
>On 06/25/2014 05:08 PM, Anton Ertl wrote:
>
>> OS library functions like open are relatively easy to handle. The
>> names live only until the end of the call to the function. So we can
>> dynamically allocate the strings and know exactly when to free them
>> (right after the library call). And we allocate them when we pass
>> them from the Forth world to the C world, i.e., at the start of the
>> call, with an explicit conversion word.
>
>But it is easier and faster and uses less memory to simply have the
>string already prepared to be sent out, no?
For string constants, yes. In general, no. E.g., if I select a
(non-trailing) substring to pass to a library function, it will not be
zero-terminated. Now I can do special-casing for string constants,
and other strings (or some other division), but it's easier to just
have a Forth word that takes the strings in Forth format ( c-addr u ),
converts them into the C format internally, and then calls the C
function. It may cost a little time and space, but we are calling an
OS function anyway, so the cost is probably swamped by the costs of
the called function.
>Besides those advantages, it is also one less thing the programmer needs
>to consider, one place fewer for a bug to occur.
That's exactly the reason why there is an interface word that provides
a Forth interface, and that does the conversion internally before
calling the C function.
>And it only costs one
>byte extra per string.
Well, if all strings (not just constants) have the trailing 0, it
costs the ability to produce substrings by manipulation address and
count. In that case it costs more bytes, and the time needed for
allocating the space for the substring and for copying it.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2014-06-25 21:03 +0300 |
| Message-ID | <lof2t6$bk2$1@dont-email.me> |
| In reply to | #31829 |
On 06/25/2014 08:14 PM, Anton Ertl wrote: > For string constants, yes. In general, no. E.g., if I select a > (non-trailing) substring to pass to a library function, it will not be > zero-terminated. Everything you say is true; most especially regarding the cost of calling the OS vs the cost of appending a NUL byte etc. That argument is somewhat less true when calling a simple library expecting a C string where there is no context-switch, but it is still pretty accurate. > That's exactly the reason why there is an interface word that provides > a Forth interface, and that does the conversion internally before > calling the C function. Actually I do the same... >> And it only costs one >> byte extra per string. > > Well, if all strings (not just constants) have the trailing 0, it > costs the ability to produce substrings by manipulation address and > count. In that case it costs more bytes, and the time needed for > allocating the space for the substring and for copying it. I see your point clearly. The difference is that in my system you cannot have a substring which merely points into another string, while you can in std Forths. If you ask for a substring in mine, you get a separate string item (which keeps track of length, and automatically takes care of memory if you append to it, etc). So since I anyway do a bunch of housekeeping on my strings, it costs me nothing more to ensure a NUL termination. This has the added benefit in my system that internals don't have to do any conversions when calling out (nor do FFI routines). Best regards, Ron
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-26 12:13 +0000 |
| Message-ID | <53ac0e6f$0$15866$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #31829 |
In article <2014Jun25.191458@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Ron Aaron <rambamist@gmail.com> writes: >> >> >>On 06/25/2014 05:08 PM, Anton Ertl wrote: >> >>> OS library functions like open are relatively easy to handle. The >>> names live only until the end of the call to the function. So we can >>> dynamically allocate the strings and know exactly when to free them >>> (right after the library call). And we allocate them when we pass >>> them from the Forth world to the C world, i.e., at the start of the >>> call, with an explicit conversion word. >> >>But it is easier and faster and uses less memory to simply have the >>string already prepared to be sent out, no? > >For string constants, yes. In general, no. E.g., if I select a >(non-trailing) substring to pass to a library function, it will not be >zero-terminated. Now I can do special-casing for string constants, >and other strings (or some other division), but it's easier to just >have a Forth word that takes the strings in Forth format ( c-addr u ), >converts them into the C format internally, and then calls the C >function. It may cost a little time and space, but we are calling an >OS function anyway, so the cost is probably swamped by the costs of >the called function. > >>Besides those advantages, it is also one less thing the programmer needs >>to consider, one place fewer for a bug to occur. > >That's exactly the reason why there is an interface word that provides >a Forth interface, and that does the conversion internally before >calling the C function. > >>And it only costs one >>byte extra per string. > >Well, if all strings (not just constants) have the trailing 0, it >costs the ability to produce substrings by manipulation address and >count. In that case it costs more bytes, and the time needed for >allocating the space for the substring and for copying it. What is not too bad is if you have a non-standard string denotation anyway, to specify that is zero-ended. But I find that even in windows programming the use is limited. Let's see, for a turnkey program, the strings must be manipulated at run time. So all strings are passed to Forth words, so they are good/real string constant (address length). / ------------------- some real code --------------------- "kernel32.DLL" LOAD-DLL: Kernel32 "Sleep" 'Kernel32 DLL-ADDRESS: Sleep : MS Sleep CALL DROP ; / -------------------------------------------------------- Maybe LOAD-DLL: and DLL-ADDRESS pass zero-ended strings to MS-WINDOWS but that is transparent. (Actually, they don't, they pass it to a Forth-word. So with a too early introduction of zero-ended strings, factoring goes through the drain, or the whole Forth get infected.) So I prefer to use Z that may be used only on a freshly allocated string in the dictionary: "open cdaudio" Z CONSTANT _cmd_open \ Open connection to a cdaudio player. It is non-obtrusive, but means that reading a program you stay aware of when string are c-strings. > >- anton -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-25 16:14 +0000 |
| Message-ID | <53aaf57b$0$4693$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #31817 |
In article <2014Jun25.160804@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >Ron Aaron <rambamist@gmail.com> writes: >>NUL terminated strings are indeed a scourge. But OS libraries often >>want them. > >OS library functions like open are relatively easy to handle. The >names live only until the end of the call to the function. So we can >dynamically allocate the strings and know exactly when to free them >(right after the library call). And we allocate them when we pass >them from the Forth world to the C world, i.e., at the start of the >call, with an explicit conversion word. Even static allocations works fine here. You never really need to do system calls in a recursive fashion. I have a cheap solution: ZEN. It copies a string to a static buffer that I have anyway. > >- anton 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2014-06-25 17:27 +0000 |
| Message-ID | <2014Jun25.192711@mips.complang.tuwien.ac.at> |
| In reply to | #31822 |
albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2014Jun25.160804@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>OS library functions like open are relatively easy to handle. The
>>names live only until the end of the call to the function. So we can
>>dynamically allocate the strings and know exactly when to free them
>>(right after the library call). And we allocate them when we pass
>>them from the Forth world to the C world, i.e., at the start of the
>>call, with an explicit conversion word.
>
>Even static allocations works fine here. You never really need to do
>system calls in a recursive fashion. I have a cheap solution: ZEN.
>It copies a string to a static buffer that I have anyway.
You may have to pass more than one string, and the strings may be of
arbitrary length.
- 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 2014: http://www.euroforth.org/ef14/
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-25 18:24 -0400 |
| Message-ID | <op.xh067le36zenlw@localhost> |
| In reply to | #31806 |
On Wed, 25 Jun 2014 04:16:28 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >> On Sun, 22 Jun 2014 22:57:55 -0400, <hughaguilar96@yahoo.com> wrote: >>> On Sunday, June 22, 2014 7:41:58 AM UTC-7, Roger Levy wrote: >> I've already told you and everyone else here the solution to that >> numerous times, but I suspect you're not going to like hearing the >> answer, again: >> >> NUL-TERMINATED STRINGS > > That would be a huge backward step. Zero-terminated strings are one > of the worst design decisions to afflict C, and more recent languages > like C++ and Java have, very sensibly, moved away from them. Forth got > this one right. > Are you joking when you claimed you maintain GCC? I was your manager, I would fire you for that *literally*, if you truly believed that. At best it's a grievous misunderstanding of computer science over the past four decades. Nul-terminated strings eliminated the errors that occur with failure to adjust the count on counted strings. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-06-26 03:27 -0500 |
| Message-ID | <iKGdnZLAuNEQRDbOnZ2dnUVZ_hKdnZ2d@supernews.com> |
| In reply to | #31848 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > On Wed, 25 Jun 2014 04:16:28 -0400, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: >> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >>> On Sun, 22 Jun 2014 22:57:55 -0400, <hughaguilar96@yahoo.com> wrote: >>>> On Sunday, June 22, 2014 7:41:58 AM UTC-7, Roger Levy wrote: > >>> I've already told you and everyone else here the solution to that >>> numerous times, but I suspect you're not going to like hearing the >>> answer, again: >>> >>> NUL-TERMINATED STRINGS >> >> That would be a huge backward step. Zero-terminated strings are one >> of the worst design decisions to afflict C, and more recent languages >> like C++ and Java have, very sensibly, moved away from them. Forth got >> this one right. > > Are you joking when you claimed you maintain GCC? I still am a maintainer, but I haven't been very active recently: I've been busy porting OpenJDK. > I was your manager, I would fire you for that *literally*, if you > truly believed that. I hope that you don't manage anyone, then. Skilled engineers IME tend to be pretty opinionated about technical issues, and while we may disagree about some of them we respect each other's opinion, or at least the right to have one. > At best it's a grievous misunderstanding of computer science over > the past four decades. ? > Nul-terminated strings eliminated the errors that occur with failure > to adjust the count on counted strings. Zero-terminated strings have two profound disadvantages: they require scanning in order to determine their length, and they need a sentinel character which is not part of the character set. The latter is particularly nasty because it requires output functions to be duplicated: you have to have both fwrite() and fputs(), for example. Also, zero-termination means in most cases that substrings can't share memory. C++ has, very sensibly, moved to strings with a separate count. As far as I know most programming language designers since C have looked at C strings and decided not to do what it does. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-26 17:50 -0400 |
| Message-ID | <op.xh20abi76zenlw@localhost> |
| In reply to | #31867 |
On Thu, 26 Jun 2014 04:27:57 -0400, Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >> Nul-terminated strings eliminated the errors that occur with failure >> to adjust the count on counted strings. > > Zero-terminated strings have two profound disadvantages: they require > scanning in order to determine their length, Most string operations act until a terminator is found, e.g., strcmp(), strcpy(). This is trivially different from decrementing a count and comparing it to zero when copying, comparing, or moving strings, etc. The difference is that no count must be maintained. The string isn't limited by the integer size of a count field. As for a programmer actually needing the length of a string, that's very infrequent. > and they need a sentinel character which is not part of the > character set. So? What computing platform doesn't support both text and binary files? Most platforms support those two and additional others. > The latter is particularly nasty because it requires output functions > to be duplicated: you have to have both fwrite() and fputs(), for > example. Many platforms have multiple file formats that required specialized reads. E.g., the CBM filesystem used in C64 1541 drives etc, which was derived from mainframe platform, supported four: REL, PRG, SEQ, and USR. The Stratus Continuum's supported numerous. I don't recall on the DEC/VAX. > Also, zero-termination means in most cases that substrings can't > share memory. That's not true. It just means you have to either 1) only use one terminator at a time (no 'const'), or 2) use memory copy or compare functions instead of string functions. It means the compiler can't easily setup substrings to share memory. That's different from me inserting and removing terminators for strings. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-06-27 03:13 -0500 |
| Message-ID | <tNGdnSyYGL4DujDOnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #31893 |
Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > On Thu, 26 Jun 2014 04:27:57 -0400, Andrew Haley > <andrew29@littlepinkcloud.invalid> wrote: >> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > >>> Nul-terminated strings eliminated the errors that occur with failure >>> to adjust the count on counted strings. >> >> Zero-terminated strings have two profound disadvantages: they require >> scanning in order to determine their length, > > Most string operations act until a terminator is found, e.g., strcmp(), > strcpy(). Well, yes. That's what they have to do if strings use a sentinel. > This is trivially different from decrementing a count and comparing > it to zero when copying, comparing, or moving strings, etc. The > difference is that no count must be maintained. The string isn't > limited by the integer size of a count field. Integers are as big as you like, so that's not an issue. Scanning for zero in a string is really not trivial: it requires some trickiness if you want to compare more than one byte at a time, and I presume you do. Also, comparison isn't quite the point here: for example, copying a string probably requires two passes, first to find its length and the to allocate the memory. > As for a programmer actually needing the length of a string, that's > very infrequent. Rubbish. >> and they need a sentinel character which is not part of the >> character set. > > So? What computing platform doesn't support both text and binary files? > Most platforms support those two and additional others. It's a bad design decision. >> The latter is particularly nasty because it requires output functions >> to be duplicated: you have to have both fwrite() and fputs(), for >> example. > > Many platforms have multiple file formats that required specialized > reads. Well, yes. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-27 12:30 +0000 |
| Message-ID | <53ad63ee$0$15860$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #31893 |
In article <op.xh20abi76zenlw@localhost>, Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: >On Thu, 26 Jun 2014 04:27:57 -0400, Andrew Haley ><andrew29@littlepinkcloud.invalid> wrote: >> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote: > >>> Nul-terminated strings eliminated the errors that occur with failure >>> to adjust the count on counted strings. >> >> Zero-terminated strings have two profound disadvantages: they require >> scanning in order to determine their length, > >Most string operations act until a terminator is found, e.g., strcmp(), >strcpy(). This is trivially different from decrementing a count and >comparing it to zero when copying, comparing, or moving strings, etc. >The difference is that no count must be maintained. The string isn't >limited by the integer size of a count field. > >As for a programmer actually needing the length of a string, that's >very infrequent. FYI. Python 3.0 has moved towards a strong separation between byte arrays and strings. Now a string contains of characters, and the coding of the character can be quite complicated. It does contain the occasional zero byte. You are WAY behind the times. (In principle Forth has the same distinction between address units and chars, but it has been worked out barely.) >Rod Pemberton -- 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 | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2014-06-25 03:46 -0700 |
| Message-ID | <39b481fe-3c92-44bc-aee7-b344fa9d523d@googlegroups.com> |
| In reply to | #31801 |
On Wednesday, 25 June 2014 02:04:05 UTC+1, Rod Pemberton wrote: > > NUL-TERMINATED STRINGS > Bullshit. What? So that COUNT has to walk a string looking for a 0, like C? No thanks. What if I want a 0 in my string? Not all strings are displayable ASCII you know! A length cell is only sensible way (note, CELL, not byte). Null terminated strings are a retarded throw-back to the COBOL universe. Bah! See what you did, Pemberton! :-)
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-25 16:15 +0000 |
| Message-ID | <53aaf5b5$0$4693$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #31812 |
In article <39b481fe-3c92-44bc-aee7-b344fa9d523d@googlegroups.com>, Mark Wills <markwills1970@gmail.com> wrote: >On Wednesday, 25 June 2014 02:04:05 UTC+1, Rod Pemberton wrote: >> >> NUL-TERMINATED STRINGS >> >Bullshit. What? So that COUNT has to walk a string looking for a 0, like >C? No thanks. > >What if I want a 0 in my string? Not all strings are displayable ASCII you know! > >A length cell is only sensible way (note, CELL, not byte). Null >terminated strings are a retarded throw-back to the COBOL universe. > >Bah! See what you did, Pemberton! :-) You've given the troll enough food, that its lives on for another two months. 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-25 13:19 -0700 |
| Message-ID | <ecbcdd48-d317-4700-b5d6-a71612aaaa5c@googlegroups.com> |
| In reply to | #31812 |
On Wednesday, June 25, 2014 3:46:13 AM UTC-7, Mark Wills wrote: > On Wednesday, 25 June 2014 02:04:05 UTC+1, Rod Pemberton wrote: > > > NUL-TERMINATED STRINGS > > Bullshit. What? So that COUNT has to walk a string looking for a 0, like C? No thanks. > > What if I want a 0 in my string? Not all strings are displayable ASCII you know! > > A length cell is only sensible way (note, CELL, not byte). Null terminated strings are a retarded throw-back to the COBOL universe. > > Bah! See what you did, Pemberton! :-) Calm down Mark --- you act as if you found a rabid coyote inside of your house. It is just a C programmer talking nonsense --- you can ignore him. In my language, I will not have any limit on the size of the strings, and I will not have a zero terminator either (because this prevents sub-strings from being processed in place). Also, I will have UTF-8 strings.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnothavet.cqm> |
|---|---|
| Date | 2014-06-25 18:52 -0400 |
| Message-ID | <op.xh08hbdb6zenlw@localhost> |
| In reply to | #31838 |
On Wed, 25 Jun 2014 16:19:56 -0400, <hughaguilar96@yahoo.com> wrote: > In my language, I will not have any limit on the size of the strings, Just how do you intend to do that? ... You said you're not going to use nul-terminated strings (below), but integers have a limited range. So, if you use counted strings, your strings will be limited to the maximum representable value for the integer used to store the strings' length. I.e., 65535 for unsigned 16-bit, 4294967295 for unsigned 32-bit, etc. 32-bits is huge, but it's still a fixed size, not unlimited as you've claimed. > and I will not have a zero terminator either That's doable. It's what Forth already does. > (because this prevents sub-strings from being processed in place). That's not true. C has nul-terminated strings and C's strtok() processes sub-strings in place. > Also, I will have UTF-8 strings. Ok. I don't see the point of using UTF-8 for words in the dictionary, but emitting UTF-8 strings for display might be useful. I'd stay with the ASCII portion of UTF-8 for word names. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web