Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16855 > unrolled thread
| Started by | Mark Wills <forthfreak@gmail.com> |
|---|---|
| First post | 2012-10-31 04:58 -0700 |
| Last post | 2012-11-02 13:13 -0400 |
| Articles | 20 on this page of 169 — 25 participants |
Back to article view | Back to comp.lang.forth
Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 04:58 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 05:22 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 05:44 -0700
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 11:29 -0400
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 11:40 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 08:45 -0700
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-02 04:48 -0400
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-10-31 21:42 -0400
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-01 19:19 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 13:06 -0400
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-02 12:18 -0500
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 14:34 -0400
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 11:39 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 14:43 -0400
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 02:36 -0600
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-04 14:18 -0500
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-02 14:38 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 03:01 -0600
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-04 03:54 -0800
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 07:59 -0600
Re: Is there a better way? Elizabeth D Rather <erather@forth.com> - 2012-11-04 08:34 -1000
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 15:22 -0800
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-05 02:39 -0800
Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-05 14:01 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-05 10:39 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-05 21:07 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-06 20:57 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-06 21:43 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-07 03:52 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 19:55 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-07 20:46 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-08 10:39 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-12 03:48 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 07:57 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-12 19:50 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-12 19:49 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 15:00 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-13 00:50 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-13 00:58 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-12 23:17 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-13 13:44 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-13 13:53 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Alex McDonald <blog@rivadpm.com> - 2012-11-13 06:39 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-13 18:02 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Alex McDonald <blog@rivadpm.com> - 2012-11-13 12:10 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-15 16:59 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-13 07:55 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:34 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-14 05:01 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-14 16:11 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 09:36 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] humptydumpty <ouatubi@gmail.com> - 2012-11-14 12:19 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-13 10:20 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] Brad Eckert <hwfwguy@gmail.com> - 2012-11-13 08:50 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:42 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-14 14:14 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-14 15:28 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-14 17:54 +0100
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-14 15:01 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Mark Wills <forthfreak@gmail.com> - 2012-11-15 00:08 -0800
Strings (was: Words consuming arguments) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-15 15:18 +0000
Re: Strings (was: Words consuming arguments) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-15 16:36 +0000
Re: Strings (was: Words consuming arguments) "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 18:35 -0500
Re: Strings (was: Words consuming arguments) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-16 00:36 +0000
Re: Strings (was: Words consuming arguments) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-16 17:42 +0000
Re: Strings (was: Words consuming arguments) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-16 17:55 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-17 04:18 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Alex McDonald <blog@rivadpm.com> - 2012-11-17 04:56 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-17 07:24 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-19 15:58 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] Brad Eckert <hwfwguy@gmail.com> - 2012-11-20 08:17 -0800
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:30 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-14 09:06 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 06:18 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-13 04:26 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-14 06:29 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-14 06:03 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 07:15 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-15 11:51 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-15 18:44 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-16 03:50 -0600
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-15 08:09 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Elizabeth D. Rather" <erather@forth.com> - 2012-11-06 21:19 -1000
Re: Words consuming arguments, was [Re: Is there a better way?] "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-11-07 20:00 -0500
Re: Words consuming arguments, was [Re: Is there a better way?] stephenXXX@mpeforth.com (Stephen Pelc) - 2012-11-08 10:49 +0000
Re: Words consuming arguments, was [Re: Is there a better way?] albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-07 14:01 +0000
Re: Is there a better way? awegel@arcor.de (Alex Wegel) - 2012-11-04 11:07 +0100
Re: Is there a better way? awegel@arcor.de (Alex Wegel) - 2012-11-04 11:36 +0100
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-04 03:48 -0800
Re: Is there a better way? awegel@arcor.de (Alex Wegel) - 2012-11-04 13:31 +0100
Re: Is there a better way? Coos Haak <chforth@hccnet.nl> - 2012-11-04 13:29 +0100
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-04 04:42 -0800
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-04 02:38 -0600
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 10:20 -0400
Re: Is there a better way? humptydumpty <ouatubi@gmail.com> - 2012-10-31 05:53 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 09:23 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 06:41 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-31 11:46 -0500
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:27 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 14:32 -0700
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-31 16:15 -0700
Re: Is there a better way? Coos Haak <chforth@hccnet.nl> - 2012-10-31 22:49 +0100
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-31 17:13 -0500
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 23:39 -0700
Re: Is there a better way? "Elizabeth D. Rather" <erather@forth.com> - 2012-10-31 20:58 -1000
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-01 02:04 -0700
Re: Is there a better way? "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-31 19:13 -0400
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-02 17:31 +0000
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 10:37 -0700
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-02 18:12 +0000
Re: Is there a better way? "Elizabeth D. Rather" <erather@forth.com> - 2012-11-02 08:29 -1000
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 14:53 +0000
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 11:30 -0700
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 00:15 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 19:21 -0400
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 00:42 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 20:21 -0400
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 01:44 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-03 12:12 -0400
Re: Is there a better way? Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-03 18:24 +0100
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-03 14:00 -0400
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-03 10:29 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-02 18:42 -0700
Re: Is there a better way? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-11-05 11:45 +0000
Re: Is there a better way? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-11-01 21:00 +0000
Re: Is there a better way? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-31 15:26 +0000
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 12:22 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 15:07 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-10-31 19:16 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 06:31 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-11-01 10:34 -0400
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-11-01 10:48 -0400
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 08:55 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 08:49 -0700
Re: Is there a better way? Doug Hoffman <glidedog@gmail.com> - 2012-11-01 12:46 -0400
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-01 09:37 -0500
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-11-01 07:41 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-01 08:52 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-01 12:18 -0500
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-01 19:38 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-02 02:29 -0700
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-11-04 21:48 -0800
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-05 02:44 -0800
Re: Is there a better way? Graham NEWS <gray@forthman.plus.com> - 2012-11-01 15:52 +0000
Re: Is there a better way? Josh Grams <josh@qualdan.com> - 2012-11-03 16:38 +0000
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:26 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-01 13:42 -0400
Re: Is there a better way? Graham <""gray\"@forthman@plus.com"> - 2012-10-31 17:05 +0000
Re: Is there a better way? Peter Fälth <peter.falth@tin.it> - 2012-10-31 12:07 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 12:12 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:17 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 14:21 -0700
Re: Is there a better way? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-31 14:50 -0700
Re: Is there a better way? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-31 14:51 -0700
Re: Is there a better way? Paul Rubin <no.email@nospam.invalid> - 2012-10-31 14:57 -0700
Re: Is there a better way? Coos Haak <chforth@hccnet.nl> - 2012-10-31 23:47 +0100
Re: Is there a better way? mhx@iae.nl (Marcel Hendrix) - 2012-11-01 21:28 +0200
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-10-31 15:11 -0700
Re: Is there a better way? Pablo Hugo Reda <pabloreda@gmail.com> - 2012-10-31 15:44 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-01 13:55 -0400
Re: Is there a better way? Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-31 16:10 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 01:10 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 01:18 -0700
Re: Is there a better way? Mark Wills <forthfreak@gmail.com> - 2012-11-02 01:58 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 02:14 -0700
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 02:16 -0700
Re: Is there a better way? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-11-02 06:16 -0500
Re: Is there a better way? Charles Mélice <charles.melice@gmail.com> - 2012-11-02 06:04 -0700
Re: Is there a better way? rickman <gnuarm@gmail.com> - 2012-11-02 13:13 -0400
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-13 13:44 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <50a24ebf$0$3205$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #17245 |
In article <6a42ffc1-3ac7-4099-905d-e5e89bccd13b@b12g2000vbg.googlegroups.com>, Mark Wills <forthfreak@gmail.com> wrote: >On Nov 13, 1:00 am, "Elizabeth D. Rather" <erat...@forth.com> wrote: >> On 11/12/12 2:49 PM, Rod Pemberton wrote: >> ... >> >> > BTW, this is the original definition of COUNT: >> >> > " COUNT addr1 --- addr2 n L0 >> > Leave the byte address addr2 and byte count n of a message >> > text beginning at addr1. It is presumed that the first >> > byte at addr1 contains the text byte count and the actual >> > text starts with the second byte. Typically COUNT is >> > followed by TYPE." >> >> > It's also more accurate. It doesn't assume counted strings. >> >> I'm not sure what "original" means in this context. COUNT has been >> around since 1971, which is 7 years before the first, very preliminary, >> attempt at standards. In any case, the sentence, "It is presumed that >> the first byte at addr1 contains the text byte count and the actual text >> starts with the second byte" is an accurate description of a counted string. >> >> 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 90045http://www.forth.com >> >> "Forth-based products and Services for real-time >> applications since 1973." >> ================================================== > >The definition of COUNT is quite interesting. It actually indirectly, >and presumably un-intentionally mandates the format of a string in >Forth. Here's the ANS definition: > >6.1.0980 COUNT >CORE > > ( c-addr1 -- c-addr2 u ) > >Return the character string specification for the counted string >stored at c-addr1. c-addr2 is the address of the first character after >c-addr1. u is the contents of the character at c-addr1, which is the >length in characters of the string at c-addr2. > > >Note the last line: u *is* the contents of the character at c-addr1... > >So, there's no way around it in actual fact. If you wanted to >implement strings in a different way under the covers, you'd be >prevented from doing so. It's slightly off topic, but I thought it >interesting. Well, no. My forth implementation revolves around strings with a cell count. I.e. even on a 64 bit system ' APE >NFA @ points to a ciforth-regular string stored in memory. So a subsequent fetch ( @ ) gives the length of the string. A $@ gives something to be passable to TYPE. COUNT is aliased as $@-BD . I feel not much constrained by the Standard, although WORD and FIND have become loadable extension. > >There is no clue to the format of a string in memory in the ANS >definition of S" : > >6.1.2165 S" >s-quote CORE > > > Interpretation: Interpretation semantics for this word are undefined. > > > Compilation: ( "ccc<quote>" -- ) > >Parse ccc delimited by " (double-quote). Append the run-time semantics >given below to the current definition. > > Run-time: ( -- c-addr u ) > >Return c-addr and u describing a string consisting of the characters >ccc. A program shall not alter the returned string. > > > >That's disappointing. If the format of a string is mandatory, then the >appropriate place to describe it (or refer to it) is within the >definition of the word S" not COUNT. Hell no. I would have had a lot of trouble using sensible strings in the core of my Forth, had the standard prescribed this. 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 | 2012-11-13 13:53 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <2012Nov13.145313@mips.complang.tuwien.ac.at> |
| In reply to | #17245 |
Mark Wills <forthfreak@gmail.com> writes:
>The definition of COUNT is quite interesting. It actually indirectly,
>and presumably un-intentionally mandates the format of a string in
>Forth. Here's the ANS definition:
>
>6.1.0980 COUNT
>CORE
>
> ( c-addr1 -- c-addr2 u )
>
>Return the character string specification for the counted string
>stored at c-addr1. c-addr2 is the address of the first character after
>c-addr1. u is the contents of the character at c-addr1, which is the
>length in characters of the string at c-addr2.
>
>
>Note the last line: u *is* the contents of the character at c-addr1...
>
>So, there's no way around it in actual fact. If you wanted to
>implement strings in a different way under the covers, you'd be
>prevented from doing so.
At least for counted strings, which I don't recommend using.
It is interesting, though, that some people write about COUNT as if
its specification was more abstract than it is.
>There is no clue to the format of a string in memory in the ANS
>definition of S" :
>
>6.1.2165 S"
>s-quote CORE
[...]
>Return c-addr and u describing a string consisting of the characters
>ccc. A program shall not alter the returned string.
The format of a c-addr u string is just that the first char is at
c-addr, the next char is at c-addr char+ etc. Hmm, but is that
anywhere in the standard text?
>That's disappointing. If the format of a string is mandatory, then the
>appropriate place to describe it (or refer to it) is within the
>definition of the word S" not COUNT.
COUNT is for counted strings, S" is for c-addr u strings, and whether
is stores the string as counted string is up to the implementation (a
high-quality S" can deal with arbitrary-length strings, there counted
strings are not an option). Neither says anything about the
arrangement of the characters themselves.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2012-11-13 06:39 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <f48232a5-0a77-433c-bfc9-780fd1b02056@j12g2000vbm.googlegroups.com> |
| In reply to | #17250 |
On Nov 13, 2:06 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Mark Wills <forthfr...@gmail.com> writes: > >The definition of COUNT is quite interesting. It actually indirectly, > >and presumably un-intentionally mandates the format of a string in > >Forth. Here's the ANS definition: > > >6.1.0980 COUNT > >CORE > > > ( c-addr1 -- c-addr2 u ) > > >Return the character string specification for the counted string > >stored at c-addr1. c-addr2 is the address of the first character after > >c-addr1. u is the contents of the character at c-addr1, which is the > >length in characters of the string at c-addr2. > > >Note the last line: u *is* the contents of the character at c-addr1... > > >So, there's no way around it in actual fact. If you wanted to > >implement strings in a different way under the covers, you'd be > >prevented from doing so. > > At least for counted strings, which I don't recommend using. > > It is interesting, though, that some people write about COUNT as if > its specification was more abstract than it is. > > > > >There is no clue to the format of a string in memory in the ANS > >definition of S" : > > >6.1.2165 S" > >s-quote CORE > [...] > >Return c-addr and u describing a string consisting of the characters > >ccc. A program shall not alter the returned string. > > The format of a c-addr u string is just that the first char is at > c-addr, the next char is at c-addr char+ etc. Hmm, but is that > anywhere in the standard text? > > >That's disappointing. If the format of a string is mandatory, then the > >appropriate place to describe it (or refer to it) is within the > >definition of the word S" not COUNT. > > COUNT is for counted strings, S" is for c-addr u strings, and whether > is stores the string as counted string is up to the implementation (a > high-quality S" can deal with arbitrary-length strings, there counted > strings are not an option). Neither says anything about the > arrangement of the characters themselves. The arrangement is specified. There's the usual Western ASCII right to left bias specifically in the normative "Terms, notation, and references" section of the standard. character string: Data space that is associated with a sequence of consecutive character-aligned addresses. Character strings usually contain text. Unless otherwise indicated, the term “string” means “character string”. Counted strings get a mention too; 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. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard:http://www.forth200x.org/forth200x.html > EuroForth 2012:http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-13 18:02 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <2012Nov13.190227@mips.complang.tuwien.ac.at> |
| In reply to | #17251 |
Alex McDonald <blog@rivadpm.com> writes:
>On Nov 13, 2:06=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Neither says anything about the
>> arrangement of the characters themselves.
>
>The arrangement is specified. There's the usual Western ASCII right to
>left bias specifically in the normative "Terms, notation, and
>references" section of the standard.
>
>character string: Data space that is associated with a sequence of
>consecutive character-aligned addresses. Character strings usually
>contain text. Unless otherwise indicated, the term =93string=94 means
>=93character string=94.
I don't see a clear specification of the arrangement. It says
"sequence of consecutive character-aligned addresses", but that does
not say anything about the order of the characters. I don't see any
right-to-left bias here, either.
Of course, given that there has not been a question on the order of
characters since Forth-94 came out, it is obviously unnecessary to
specify the order of characters in more detail, at least for the main
purpose of the standard.
>Counted strings get a mention too;
>
>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.
This clearly specifies the count concretely, but the other characters
still have no specified order.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Alex McDonald <blog@rivadpm.com> |
|---|---|
| Date | 2012-11-13 12:10 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <63bee032-0471-4a95-b950-2db25af2c8b0@s14g2000vba.googlegroups.com> |
| In reply to | #17255 |
On Nov 13, 6:09 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Alex McDonald <b...@rivadpm.com> writes:
> >On Nov 13, 2:06=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> Neither says anything about the
> >> arrangement of the characters themselves.
>
> >The arrangement is specified. There's the usual Western ASCII right to
> >left bias specifically in the normative "Terms, notation, and
> >references" section of the standard.
>
> >character string: Data space that is associated with a sequence of
> >consecutive character-aligned addresses. Character strings usually
> >contain text. Unless otherwise indicated, the term =93string=94 means
> >=93character string=94.
>
> I don't see a clear specification of the arrangement. It says
> "sequence of consecutive character-aligned addresses", but that does
> not say anything about the order of the characters. I don't see any
> right-to-left bias here, either.
3.1.4.2 Character strings
A string is specified by a cell pair (c-addr u) representing its
starting address and length in characters.
For non-Western orderings, this is possible if c-addr points at the
starting address (c-addr+u) and the string extends (conceptually)
leftwards or through decreasing addresses. But then;
17.6.1.0245 /STRING “slash-string” STRING
( c-addr1 u1 n -- c-addr2 u2 )
Adjust the character string at c-addr1 by n characters. The resulting
character string, specified by c-addr2 u2, begins at c-addr1 plus n
characters and is u1 minus n characters long.
makes such an ordering impossible to implement. Of course, the string
could be held backwards ("sdrawkcab"), but then that introduces a
whole set of other issues; for instance, how would we interpret the
result of 1 /STRING ? How should a SEARCH for the character 'a' in the
example given operate?
>
> Of course, given that there has not been a question on the order of
> characters since Forth-94 came out, it is obviously unnecessary to
> specify the order of characters in more detail, at least for the main
> purpose of the standard.
>
Many (most?) standards have this issue, so I wouldn't consider it a
defect.
> >Counted strings get a mention too;
>
> >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.
>
> This clearly specifies the count concretely, but the other characters
> still have no specified order.
As above, since the result of COUNT must be treatable by /STRING;
therefore they must have the order left to right at ascending
addresses.
>
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard:http://www.forth200x.org/forth200x.html
> EuroForth 2012:http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-15 16:59 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <2012Nov15.175942@mips.complang.tuwien.ac.at> |
| In reply to | #17256 |
Alex McDonald <blog@rivadpm.com> writes:
>On Nov 13, 6:09=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> I don't see a clear specification of the arrangement. =A0It says
>> "sequence of consecutive character-aligned addresses", but that does
>> not say anything about the order of the characters. =A0I don't see any
>> right-to-left bias here, either.
>
>3.1.4.2 Character strings
>A string is specified by a cell pair (c-addr u) representing its
>starting address and length in characters.
>
>For non-Western orderings, this is possible if c-addr points at the
>starting address (c-addr+u) and the string extends (conceptually)
>leftwards or through decreasing addresses. But then;
I would not expect writing direction to be reflected in memory
ordering of a string. I.e., for a latin ("western") text, I would
expect the first character in memory to be written/displayed leftmost
in the top line, for a Hebrew text rightmost in the top line, for a
Japanese text topmost in the right column. Memory ordering has no
cultural bias (except that there is something like a writing order)
then.
Why would you have a Hebrew or Japanese string grow towards lower
addresses? Programs would just fail to work properly.
>> This clearly specifies the count concretely, but the other characters
>> still have no specified order.
>
>As above, since the result of COUNT must be treatable by /STRING;
>therefore they must have the order left to right at ascending
>addresses.
But /STRING says nothing about the order of characters either, it just
talks about addresses:
>17.6.1.0245 /STRING =93slash-string=94 STRING
>( c-addr1 u1 n -- c-addr2 u2 )
>Adjust the character string at c-addr1 by n characters. The resulting
>character string, specified by c-addr2 u2, begins at c-addr1 plus n
>characters and is u1 minus n characters long.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-13 07:55 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <2ae8f57b-f995-4732-be93-6ffb90491b0f@q1g2000vbx.googlegroups.com> |
| In reply to | #17250 |
On Nov 13, 2:06 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Mark Wills <forthfr...@gmail.com> writes: > >The definition of COUNT is quite interesting. It actually indirectly, > >and presumably un-intentionally mandates the format of a string in > >Forth. Here's the ANS definition: > > >6.1.0980 COUNT > >CORE > > > ( c-addr1 -- c-addr2 u ) > > >Return the character string specification for the counted string > >stored at c-addr1. c-addr2 is the address of the first character after > >c-addr1. u is the contents of the character at c-addr1, which is the > >length in characters of the string at c-addr2. > > >Note the last line: u *is* the contents of the character at c-addr1... > > >So, there's no way around it in actual fact. If you wanted to > >implement strings in a different way under the covers, you'd be > >prevented from doing so. > > At least for counted strings, which I don't recommend using. > > It is interesting, though, that some people write about COUNT as if > its specification was more abstract than it is. > > > > >There is no clue to the format of a string in memory in the ANS > >definition of S" : > > >6.1.2165 S" > >s-quote CORE > [...] > >Return c-addr and u describing a string consisting of the characters > >ccc. A program shall not alter the returned string. > > The format of a c-addr u string is just that the first char is at > c-addr, the next char is at c-addr char+ etc. Hmm, but is that > anywhere in the standard text? > > >That's disappointing. If the format of a string is mandatory, then the > >appropriate place to describe it (or refer to it) is within the > >definition of the word S" not COUNT. > > COUNT is for counted strings, S" is for c-addr u strings, and whether > is stores the string as counted string is up to the implementation (a > high-quality S" can deal with arbitrary-length strings, there counted > strings are not an option). Neither says anything about the > arrangement of the characters themselves. > > - anton > -- > M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html > comp.lang.forth FAQs:http://www.complang.tuwien.ac.at/forth/faq/toc.html > New standard:http://www.forth200x.org/forth200x.html > EuroForth 2012:http://www.euroforth.org/ef12/- Hide quoted text - > > - Show quoted text - Of course. You're right. Elizabeth too. I really should pay more attention. Somehow I never made the mental *dis*connect between counted strings and c-addr u strings, which are very different from each other. I implemented them both in my system and they work just fine. If I do S" HELLO" I get 5 and an address on the stack. On the other hand, when I use file streams, I get a counted stream back (by design): PAD myFile #GET ABORT" Can't read from the file" PAD COUNT TYPE Yet somehow, I'd never really considered them to be different, just the same, but in different states: c-addr u is for carrying around on the stack when you want to do work with them. Counted strings on the other hand is how they are stored in memory. I wonder if my version of S" is a hybrid of both techniques? It's the classic state-smart implementation as far as I'm aware. If used in interpretation state, it places the string in a transitory/temporary memory area and pushes len addr to the stack. If compiled, it compiles (S") len <s t r i n g> to memory. At run time, len is pushed by (S") and the address is *derived* (by (S")) by examining the Forth VM IP. Interesting subject.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-14 06:34 -0500 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7vvcr$2o5$1@speranza.aioe.org> |
| In reply to | #17252 |
"Mark Wills" <forthfreak@gmail.com> wrote in message news:2ae8f57b-f995-4732-be93-6ffb90491b0f@q1g2000vbx.googlegroups.com... ... > Of course. You're right. Elizabeth too. I really should pay more > attention. Somehow I never made the mental *dis*connect between > counted strings and c-addr u strings, which are very different from > each other. Why? Why are they different? Why should they be different? I have but one string format for Forth. It's not a counted string format. Why would I implement two string formats? An address describes a string adequately. An address and length does so too. > Yet somehow, I'd never really considered them to be different, just > the same, but in different states: c-addr u is for carrying around on > the stack when you want to do work with them. Counted strings on the > other hand is how they are stored in memory. I see your confusion as resulting from a lack of familiarity with C's string model. Ms. Rather has demonstrated similar confusion in the past when discussing the merits of null terminated strings of C versus counted strings of Forth and PL/1. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-14 05:01 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <257b37f9-69a9-4b6c-89e6-5528b89fa7bc@h16g2000vby.googlegroups.com> |
| In reply to | #17268 |
On Nov 14, 11:30 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > "Mark Wills" <forthfr...@gmail.com> wrote in message > > news:2ae8f57b-f995-4732-be93-6ffb90491b0f@q1g2000vbx.googlegroups.com... > ... > > > Of course. You're right. Elizabeth too. I really should pay more > > attention. Somehow I never made the mental *dis*connect between > > counted strings and c-addr u strings, which are very different from > > each other. > > Why? Why are they different? Why should they be different? > They're different because they're, well... different! S" Hello" results in c-addr u C" Hello" results in addr and requires COUNT to convert it to c-addr u. The advantage of the latter is it is more convenient to carry about on the stack; you only have to carry the address around, not the address *and* the length. When you want the length, COUNT will get it for you. They are different. Clearly. Though the *storage format* (how it is stored in memory) is probably the same. A C" string, when executed, will push the address of the count cell. A S" string, when executed will push the address of the the first character, and the length. *Intenrally* they are probably stored in memory in the same way, so, yes, I can see why you might say they are the same! I say *probably* stored in the same way, because they don't have to be. In the early days, my system compiled a string like this: S" hello" LIT addr LIT 5 branch xxx h e l l o _ Where the branch jumps over the string payload and _ is an alignment padding byte. This is probably how most beginners approach it. Later, I modified it to store a counted string, so S" hello" now compiles: (S") 5 h e l l o while C" hello" compiles (C") 5 h e l l o Stored in the same way, but different effects at run time. That's what I was getting at, though I admit probably not explained very well. > I have but one string format for Forth. It's not a counted string format. > > Why would I implement two string formats? > You don't have to. Just implement counted strings. COUNT converts a counted string to a c-addr u string that words like TYPE need. > I see your confusion as resulting from a lack of familiarity > with C's string model. Ms. Rather has demonstrated similar > confusion in the past when discussing the merits of null > terminated strings of C versus counted strings of Forth and PL/1. > > Rod Pemberton <troll> And don't get me started on C's crack-smoking "bunch o' bytes with a / 0 at the end"! Pants method of string storage! For reasons well trodden in previous CLF threads. </troll>
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2012-11-14 16:11 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <50a3c29c$0$3194$e4fe514c@dreader35.news.xs4all.nl> |
| In reply to | #17271 |
In article <257b37f9-69a9-4b6c-89e6-5528b89fa7bc@h16g2000vby.googlegroups.com>, Mark Wills <forthfreak@gmail.com> wrote: >On Nov 14, 11:30 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> >wrote: >> "Mark Wills" <forthfr...@gmail.com> wrote in message >> >> news:2ae8f57b-f995-4732-be93-6ffb90491b0f@q1g2000vbx.googlegroups.com... >> ... >> >> > Of course. You're right. Elizabeth too. I really should pay more >> > attention. Somehow I never made the mental *dis*connect between >> > counted strings and c-addr u strings, which are very different from >> > each other. >> > > >> Why? Why are they different? Why should they be different? >> > >They're different because they're, well... different! > >S" Hello" results in c-addr u > >C" Hello" results in addr and requires COUNT to convert it to c-addr >u. > >The advantage of the latter is it is more convenient to carry about on >the stack; you only have to carry the address around, not the address >*and* the length. When you want the length, COUNT will get it for you. The main advantage shouldn't be missed. Using c-addr u consistently, an implementation can interpret a buffer without copying things around all the time. If you use FIND you're almost obliged to. 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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-11-14 09:36 -1000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <lK2dnaOBAcdSbz7NnZ2dnUVZ_sudnZ2d@supernews.com> |
| In reply to | #17271 |
On 11/14/12 3:01 AM, Mark Wills wrote: > On Nov 14, 11:30 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: >> "Mark Wills" <forthfr...@gmail.com> wrote in message >> >> news:2ae8f57b-f995-4732-be93-6ffb90491b0f@q1g2000vbx.googlegroups.com... >> ... >> >>> Of course. You're right. Elizabeth too. I really should pay more >>> attention. Somehow I never made the mental *dis*connect between >>> counted strings and c-addr u strings, which are very different from >>> each other. >> > > >> Why? Why are they different? Why should they be different? >> > > They're different because they're, well... different! They're different in that a "counted string" is a storage format, and 'c-addr u' is a stack notation providing the address and length of a string independent of its storage format. Address alone cannot define a string; you need some way to know how long the string is, either by knowing its storage format (e.g., 'counted string' or null-terminated) or by having a length on the stack in addition to the address. 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 | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2012-11-14 12:19 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <cfbae6d8-df0f-45c1-a932-d940a65d77a8@googlegroups.com> |
| In reply to | #17279 |
On Wednesday, November 14, 2012 7:36:48 PM UTC, Elizabeth D. Rather wrote: > On 11/14/12 3:01 AM, Mark Wills wrote: > > > On Nov 14, 11:30 am, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > > > wrote: > > >> "Mark Wills" <forthfr...@gmail.com> wrote in message > > >> > > >> news:2ae8f57b-f995-4732-be93-6ffb90491b0f@q1g2000vbx.googlegroups.com... > > >> ... > > >> > > >>> Of course. You're right. Elizabeth too. I really should pay more > > >>> attention. Somehow I never made the mental *dis*connect between > > >>> counted strings and c-addr u strings, which are very different from > > >>> each other. > > >> > > > > > > > > >> Why? Why are they different? Why should they be different? > > >> > > > > > > They're different because they're, well... different! > > > > They're different in that a "counted string" is a storage format, and > > 'c-addr u' is a stack notation providing the address and length of a > > string independent of its storage format. > > > > Address alone cannot define a string; you need some way to know how long > > the string is, either by knowing its storage format (e.g., 'counted > > string' or null-terminated) or by having a length on the stack in > > addition to the address. > > > > 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." > > ================================================== Yes, in `c-addr u' case I have *explicitly* a zone of memory that will be treated as a `string'. *No more information* is needed. In `a' case I need *more information* to describe how to treat this address. Have a nice day, humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-11-13 10:20 -0600 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <adWdnWxfTuup7j_NnZ2dnUVZ8vGdnZ2d@supernews.com> |
| In reply to | #17245 |
Mark Wills <forthfreak@gmail.com> wrote: > The definition of COUNT is quite interesting. It actually indirectly, > and presumably un-intentionally mandates the format of a string in > Forth. It mandates (assumes?) the format of a counted string, and quite deliberately so. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Brad Eckert <hwfwguy@gmail.com> |
|---|---|
| Date | 2012-11-13 08:50 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <dd81c9f3-75f7-49b2-bd04-5aea88b4cb95@googlegroups.com> |
| In reply to | #17245 |
On Tuesday, November 13, 2012 1:50:25 AM UTC-7, M.R.W Wills wrote: > That's disappointing. If the format of a string is mandatory, then the > appropriate place to describe it (or refer to it) is within the > definition of the word S" not COUNT. There's no reason S" can't store the string length as a long. ANS made an effort to promote the ( c-addr ulength ) string format and also support legacy counted strings. I don't use S" and ." in my larger apps anyway, because of internationalization needs. In any given application domain, you can probably throw out half of ANS and not miss it.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-11-14 06:42 -0500 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <k7vvqm$3qv$1@speranza.aioe.org> |
| In reply to | #17245 |
"Mark Wills" <forthfreak@gmail.com> wrote in message news:6a42ffc1-3ac7-4099-905d-e5e89bccd13b@b12g2000vbg.googlegroups.com... ... > The definition of COUNT is quite interesting. It actually indirectly, > and presumably un-intentionally mandates the format of a string in > Forth. > > [This is at least second time the ANS COUNT definition > was posted in this thread ...] ... Yes. The ANS COUNT definition defines a string as counted, or more precisely assumes a counted string. As long as the stack arguments are functionally correct, the verbal definition is irrelevant. fig-Forth by using the word "presumes" doesn't define a string as counted. It allows for non-counted string implementations also. > Note the last line: u *is* the contents of the character at c-addr1... Yes. Also note that Ms. Rather has stated in the past that the count isn't required to be a character in size for Forth. IIRC, she suggested a word (16-bits) be used for a the count of a counted string. > So, there's no way around it in actual fact. If you wanted to > implement strings in a different way under the covers, you'd be > prevented from doing so. Wrong, or it should be wrong if it isn't. Officially, the ANS Forth specifications don't support a machine model. Defining a string format requires a machine model model to be defined in part. Numerous Forth "experts" here have even stated ANS doesn't define a machine model. Earlier Forth specifications did define a machine model. Supposedly, those specifications were very problematic because the fixed the sizes of integers and addresses were hardcoded and inflexible. Well, string formats are no different and would suffer the same problem. I.e., you have to take the ANS COUNT definition requiring counted strings as "wrong". > [more ANS stuff] ANS Forth specification has a variety of errors in it. E.g., "immediacy" is not required for ; semicolon. > If the format of a string is mandatory, then the > appropriate place to describe it (or refer to it) is within the > definition of the word S" not COUNT. The appropriate place is *before* definitions, but the string format shouldn't be defined. If it is, then the specification hasn't been fully abstracted from the machine model, i.e., the Forth specification authors failed in their jobs. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | stephenXXX@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2012-11-14 14:14 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <50a3979c.195921062@192.168.0.50> |
| In reply to | #17269 |
On Wed, 14 Nov 2012 06:42:19 -0500, "Rod Pemberton" <do_not_have@notemailnotz.cnm> wrote: >Yes. Also note that Ms. Rather has stated in the past that the count isn't >required to be a character in size for Forth. IIRC, she suggested a word >(16-bits) be used for a the count of a counted string. In order to test the ANS model, JaxForth used 16 bit characters. As a consequence, the unit of COUNT was 16 bit items on a byte-addressed machine. : count ( addr1 -- addr2 len ) dup w@ swap 2 + ; There is common practice in some Forth shops to use COUNT to step through memory. To resolve this, and to cope with multi-byte character sets including UTF-8, the Forth200x document treats the word "character" as meaning a primitive character, usually a byte, from which wide characters and multibyte characters are derived. COUNT now refers to a byte count followed by primitive characters. Counted strings are just a storage mechanism, in the same way that zero terminated strings are a storage mechanism. Serious string libraries work in terms of objects or structures whose internal format is unlikely to be either 8-bit counted or zero terminated. These days, in order to write internationalised applications for OS X and Windows, the programmer is likely to standardise on UTF-16. See http://site.icu-project.org/ for an example library. As a result, the relevance of counted and zero terminated strings in larger applications is really a kernel issue rather than an application issue. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2012-11-14 15:28 +0000 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <2012Nov14.162821@mips.complang.tuwien.ac.at> |
| In reply to | #17273 |
stephenXXX@mpeforth.com (Stephen Pelc) writes:
>On Wed, 14 Nov 2012 06:42:19 -0500, "Rod Pemberton"
><do_not_have@notemailnotz.cnm> wrote:
>
>>Yes. Also note that Ms. Rather has stated in the past that the count isn't
>>required to be a character in size for Forth. IIRC, she suggested a word
>>(16-bits) be used for a the count of a counted string.
>
>In order to test the ANS model, JaxForth used 16 bit characters. As
>a consequence, the unit of COUNT was 16 bit items on a byte-addressed
>machine.
>
>: count ( addr1 -- addr2 len )
> dup w@ swap 2 +
>;
A standard implementation of COUNT is:
: count ( c-addr1 -- c-addr2 u )
dup c@ swap char+ ;
This works on all standard Forth systems, even on JaxForth, and if
COUNT in JaxForth was defined in high-level, I would be surprised if
it did not use a standard-compliant definition of COUNT.
In any case, COUNT in every Forth standard I know of is required to
use a character-sized count. In Forth-94 characters can be wider than
8 bits, however.
>COUNT now refers to a byte count followed by primitive characters.
Or, more generally, a (p)char count followed by (p)chars.
>These days, in order to write internationalised applications
>for OS X and Windows, the programmer is likely to standardise
>on UTF-16.
UTF-16 is the dead-end extension of UCS-2, which became obsolete with
Unicode 2.0. It is present in some systems that were designed around
1990, like Windows NT and Java, but even there it's not universal.
Even if you have to interface with UTF-16-based Windows API functions,
I would recommend designing your interfaces such that they continue to
work if you switch to UTF-8-based API functions (switching to stuff
like Big5 and GB then is probably no additional effort).
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2012-11-14 17:54 +0100 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <1469753.NXEqTnUHyq@sunwukong.fritz.box> |
| In reply to | #17274 |
Anton Ertl wrote: >>These days, in order to write internationalised applications >>for OS X and Windows, the programmer is likely to standardise >>on UTF-16. > > UTF-16 is the dead-end extension of UCS-2, which became obsolete with > Unicode 2.0. It is present in some systems that were designed around > 1990, like Windows NT and Java, but even there it's not universal. > Even if you have to interface with UTF-16-based Windows API functions, > I would recommend designing your interfaces such that they continue to > work if you switch to UTF-8-based API functions (switching to stuff > like Big5 and GB then is probably no additional effort). Given that both Cocoa and Win32 like "zero terminated strings", you better not use their strings as native objects in Forth, but convert on the fly when you call Cocoa or Win32. We don't have that in libcc.fs now, but I suggest we should have a datatype string, which is addr len in Forth, and 0-terminated char* in C, and converted on call/return. For UTF-16 a string16 type (which still is UTF-8 on the Forth side). It should be noted that Cocoa strings are a rather complex object, and when you feed data in or get data out, you can select the encoding - both UTF-8 and UTF-16 are first class encodings. Once it's inside Cocoa's string class, you access it through Objective-C methods, and don't care about internal repesentation. It's a lot better with Xlib. There, strings are represented as addr len entities (yes, *the* addr len you use in Forth anyways, number of bytes/pchars for Utf8, no zero termination needed), with Utf8 as the preferred first-class encoding. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-11-14 15:01 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <382aa55e-7d0f-41ec-942b-e825573591f2@r10g2000pbd.googlegroups.com> |
| In reply to | #17273 |
On Nov 14, 7:15 am, stephen...@mpeforth.com (Stephen Pelc) wrote: > There is common practice in some Forth shops to use COUNT to step > through memory. To resolve this, and to cope with multi-byte > character sets including UTF-8, the Forth200x document treats the > word "character" as meaning a primitive character, usually a byte, > from which wide characters and multibyte characters are derived. > > COUNT now refers to a byte count followed by primitive characters. Even when I was 18 and programming the Vic-20, I knew better than to use COUNT for stepping through an array of chars. For one thing, it won't work if chars are assumed to be 2 bytes and/or the count is 2 bytes, which was possible even on a 6502 (especially the count being 2 bytes, although chars were generally always 1 byte in those days). For another thing, it makes for unreadable code, as the reader has to wonder: "Why is COUNT being used? What is being counted?". I wrote a word that did the same thing --- I think I called it c@c+ and there was also w@w+ that was for stepping through an array of words --- or something like that. I knew about the concept of abstraction way back then when most of the Forth community was doing things like using COUNT to step through char arrays or using 2+ for word arrays on the assumption that words were inherently 2 bytes in size, and so forth. Back in the 1980s, there seemed to be a lot of Forthers who didn't understand basic programming concepts such as abstraction --- and, that is true today too. I don't think that I will support counted strings at all in Straight Forth (I mean, strings with the count stored in the 0'th array element). I will only support adr,len strings (the address of the char array and the size of the array on the stack). I have a doubles stack that is distinct from the parameter stack. This is for double numbers and also for adr,len strings. I will also have a float stack that is distinct from the parameter stack and is for floating-point numbers. I may actually have two float stacks, one for low-precision and one for high-precision floats. Modern processors have beaucoup registers, so there is no need to mix data types together on the parameter stack, which results in a lot of ugly stack-juggling --- each data type will have its own stack in Straight Forth --- each stack will have a register dedicated as its stack-pointer. BTW Stephen --- I downloaded your VFX evaluation Forth system. So far all I have done is cycle through the "tip of the day." When I get time however, I will try to compile and run the novice package. If VFX works correctly, this will be the first time ever. In all of the other Forth systems that I have tried (SwiftForth, Gforth, Win32Forth and FICL), doing this revealed bugs in the Forth system, and I had to rewrite some portion of the novice package to work-around the bug (FICL had so many problems that I didn't support it, but the others did get supported).
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <forthfreak@gmail.com> |
|---|---|
| Date | 2012-11-15 00:08 -0800 |
| Subject | Re: Words consuming arguments, was [Re: Is there a better way?] |
| Message-ID | <9005caf6-9a4a-45e6-9d8d-9d07a7f7a3ee@c20g2000vbz.googlegroups.com> |
| In reply to | #17285 |
On Nov 14, 11:01 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > I don't think that I will support counted strings at all in Straight > Forth (I mean, strings with the count stored in the 0'th array > element). I will only support adr,len strings (the address of the char > array and the size of the array on the stack). I'm not so sure that's a good idea. The advantage of counted strings is that they are significantly easier to carry about on the stack: c" red" c" green" c" blue" is much nicer than s" red" s" green" s" blue" because with the former there are only 3 items on the stack, not 6. You determine the length of the string you are about to work with *at the point when you're going to work with it" (with COUNT), which is *much* nicer (IMHO) than carrying and juggling 6 items around on the stack! FWIW!
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.forth
csiph-web